GRASP Principles

Creator says: give the job of making a new object to a class that already aggregates, contains, records, closely uses, or holds the data needed to build it. That class already knows about it, so creating it adds no new coupling.

Cohesion is how well everything inside one class belongs together. High Cohesion says a class should keep a small set of closely related responsibilities, so it stays easy to name, understand, change, test and reuse.

Indirection says: when two components would otherwise be wired directly together, put a third object between them to mediate. Neither side knows the other, so each can change or be replaced independently.

Give a job to the object that already holds the data needed to do it. If an order knows its line items, the order should compute its own total, instead of another class pulling the items out first.

Low Coupling (GRASP) says: assign responsibilities so each class depends on as few other classes as possible. Fewer dependencies mean a change in one place breaks fewer others, and classes are easier to reuse, understand and test alone.

When behavior differs depending on the kind of thing you have, don't write an if/switch that checks the kind. Give each kind its own version of the operation behind one shared interface, and let the call pick the right version.

Protected Variations says: find the parts most likely to change or vary, and put a stable interface in front of them. Other code depends on that interface, so a change stays contained instead of rippling outward.

Pure Fabrication says: when no real-world domain concept can hold a responsibility without spoiling the design, invent a made-up, behavior-only class for it — such as a repository, mapper, or validator — to keep cohesion high and coupling low.

A facade controller is one object handling all events of a system — simple, fine for small apps. A use-case controller handles one scenario each — more classes, but each stays small and cohesive. Start with a facade; split when it grows.

Aggregates/contains means it holds the object; records means it logs instances; closely uses means it works with it heavily; has initializing data means it already knows the constructor arguments. If several fit, prefer the owner (aggregator/container); otherwise the one with the data.

They pull against each other. Splitting a class to make it more focused creates more classes that must talk to each other, raising coupling. Merging classes to cut dependencies makes each one do too much. You look for the balance point.

They describe different reasons for the same extra class. Protected Variations is the goal (shield callers from change). Indirection is the mechanism (put an object in between). Pure Fabrication is the licence to invent a non-domain class to do it.

Information Expert says the object holding the data should do the work. That is exactly what "Tell, Don't Ask" asks for: call a method on the object instead of reading its fields and deciding outside. When you break both, entities become data bags with all logic in services — the anemic domain model.

Create a PaymentMethod abstraction with fee(), settlementDelay(), and renderReceipt(). Add one class per method implementing all three. Map the stored string to a class once, in a factory. Callers just call the operations — the three switches disappear.

They aim at the same goal from different angles. Protected Variations is the general statement — wrap predicted change behind a stable interface. Open/Closed, Dependency Inversion and information hiding are specific, more prescriptive ways of doing exactly that.

Order holds the data, but saving needs SQL, connections, and transactions — infrastructure knowledge. Putting save() on Order mixes two unrelated jobs and ties the business class to the database. A separate OrderRepository keeps each focused and swappable.

Saving an object to a database. A Sale knows all its own data, so Information Expert literally says sale.save(). That would force every domain class to know SQL and transactions. Instead use Pure Fabrication: a SaleRepository invented purely for design reasons.

Information Expert proposes a home for a responsibility; Low Coupling checks the bill. If the expert class would have to depend on infrastructure or many collaborators, move the responsibility to a made-up helper class — a Pure Fabrication — that keeps the domain class clean.

Protect where change is genuinely likely and expensive to retrofit — external systems, business rules, regulated logic, vendor choices. Skip it where change is unlikely or cheap to make later; unused abstractions are pure cost: more indirection, harder reading, harder debugging.

A web/MVC controller belongs to the presentation layer — it knows about requests, responses and views. GRASP's controller must not know any of that. The claim is only true if the endpoint just translates input, calls a use-case object, and formats the reply.

The Order should build the line, because it contains and owns its lines and holds the collection they join. If the controller builds it, the controller must know the line type, the order must expose its internal list, and totals or duplicate rules can silently break.

From worst to best: coincidental (random stuff together), logical (same category), temporal (runs at the same time), procedural/communicational (same sequence or same data), sequential (output feeds the next step), and functional (everything serves one single task). Aim for functional.

All put an object in the middle, but for different jobs: Adapter translates between two vocabularies, Mediator coordinates many peers, Controller receives input events, Facade simplifies a big subsystem, Repository hides storage, Proxy stands in for the real thing.

From worst to best: content (one element reaches into another's internals), common (shared global state), external (shared external format), control (one passes a flag telling the other what to do), stamp (passes a whole record when only a field is needed), and data (passes just the values needed).

Keep the conditional when there is only one place that branches, when the variants come from code you can't subclass, when you're at a parsing boundary turning data into objects, or when the set of variants is closed and you want the compiler to check you handled all of them.

Interfaces are only one option. You can also move variation into data or configuration, use an adapter or facade around an external system, look implementations up at runtime, publish events instead of calling recipients, or adopt a standard format so vendors are interchangeable.

That's a bloated controller: it receives too many events, does the work itself, and holds too much. Fix it by splitting into one coordinator per use case and pushing the actual rules down into the domain objects that own the data.

Inject long-lived collaborators — services, repositories, gateways, clients — wired once at startup. Keep creating short-lived, data-carrying objects (entities, value objects, events, DTOs) inside the class that owns or has their data, as Creator says. When both are needed, inject a factory.

Deviate when construction is complicated or must vary: choosing among subclasses, reading configuration, caching or pooling, many optional parameters, or needing infrastructure like a clock or database. Then a factory keeps the owning class simple and lets the built type change.