Classes

A class defines a set of objects that share the same structure, their state, and the same behaviour, their methods. In design terms the more useful view is that a class is a bundle of responsibilities: things it knows and things it does, fulfilled alone or by collaborating with other classes. Rebecca Wirfs-Brock's responsibility-driven design starts from behaviour: list what the system must do, assign each responsibility to the class best placed to fulfil it, and let the fields follow. Order knows its lines and computes its total, while CheckoutService coordinates payment and stock. Starting from data instead tends to produce anemic classes with logic scattered across services.

A CRC card is an index card with three parts: the Class name, its Responsibilities, and its Collaborators, the other classes it needs to fulfil them. Kent Beck and Ward Cunningham introduced CRC cards in 1989 as a lightweight way to design object models. A team writes one card per candidate class, then walks through a use case such as checkout, passing control from card to card. Missing collaborators, misplaced responsibilities and overloaded classes become obvious quickly. The small card is a deliberate constraint: if a class's responsibilities do not fit, it is probably doing too much. Cards are cheap to rewrite, which encourages exploring alternatives before any code exists.

Information Expert says: assign a responsibility to the class that already has the information needed to fulfil it. If Order holds its OrderLines, Order should compute its total, rather than an OrderService pulling the lines out through getters and adding them up. Keeping behaviour next to its data raises cohesion, avoids getters that expose internals, and means a change to how lines are stored stays inside one class. It is the most frequently applied of Craig Larman's GRASP principles. It is not absolute, though: if following it would drag persistence or UI concerns into a domain class, Pure Fabrication suggests a separate class, such as a repository, instead.

Interface inheritance shares only a contract. A class that implements an interface promises to provide certain methods and can be used polymorphically, but it inherits no state and, apart from default methods, no implementation. Implementation inheritance, extending a class, shares the contract plus fields, behaviour and the constructor chain. That makes the subclass depend on the superclass's internal details, so a change in the parent can silently break children, the fragile base class problem. Prefer interfaces plus composition for reuse and variation. Use implementation inheritance only for a genuine, stable is-a relationship where the superclass was designed and documented for extension, or for a closed sealed hierarchy.

It usually means the class has several responsibilities. Each injected dependency is a collaborator, and when an OrderService needs nine of them, such as a repository, payment gateway, mailer, PDF renderer, tax table, stock client, audit log, metrics and feature flags, it is coordinating several unrelated concerns. Such classes change for many reasons and are hard to test. The fix is to split by responsibility: keep a coordinator with two to four collaborators, move rules such as tax into the domain object or policy that owns them, and let side effects like mail, PDF and audit react to a domain event such as OrderPaid. Hiding the dependencies behind a facade is not a fix.

Because Java runs the superclass constructor before the subclass's field initialisers and constructor body. If Base's constructor calls an overridable method such as init(), dynamic dispatch runs the subclass's override while the subclass's fields still hold default values: null, zero or false. Even final fields are not yet assigned. In the classic example, Sub's init() adds to an items list that is still null and throws a NullPointerException, or worse, silently works on broken state. The rule is that constructors should call only private, static or final methods. If setup needs subclass input, pass it as a constructor argument or use a static factory that fully constructs the object before calling any hooks.

Sealed hierarchies are a good use of inheritance when the set of subtypes is closed and known, and the variation is part of the domain rather than an extension point for others. A Payment that is either a CardPayment or a BankTransfer, or a Redemption result with three outcomes, are typical cases. Declaring the type sealed with permits lets the compiler check exhaustive switch pattern matching, so adding a new subtype breaks every switch that does not handle it, which is exactly what you want. Records as permitted subtypes keep each variant small and immutable. If third parties must add variants, or variants change often, use an open interface with strategies instead.

Responsibility-driven design scales from classes to services. A service, like a class, is a bundle of responsibilities, and the same questions apply: which capability does it own, what information does it need, and with whom must it collaborate? Information Expert becomes assigning a capability to the service that owns the data, so pricing lives with the catalogue data it needs rather than being assembled from remote calls. Narrow, directed collaborations become small APIs and dependencies that point towards stable services. A coordinator class mirrors an orchestrating service, while event-driven collaboration mirrors choreography. Clear ownership of each responsibility is what keeps services from becoming a chatty, tightly coupled distributed monolith.