How does the GRASP Indirection principle differ from the GRASP principles Pure Fabrication and Protected Variations, given that all three often produce the same extra class?

## Setting the scene GRASP (*General Responsibility Assignment Software Patterns*) contains nine principles for deciding which object gets which responsibility. Three of them — **Indirection**, **Pure Fabrication**, and **Protected Variations** — are the "advanced" trio, and in an interview they are routinely conflated because applying any of them tends to produce an extra class in the middle. The distinction is one of *question answered*, not of resulting diagram. ### Protected Variations — the WHY (policy / goal) > *Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.* Key words: **predicted**, **stable interface**. You must be able to name the axis: "the payment vendor will change", "we will support both Postgres and an in-memory store in tests", "the file format has versions". Protected Variations is essentially GRASP's statement of the Open–Closed Principle and of information hiding (Parnas: modularize around *decisions likely to change*). It is a **goal**. It does not tell you what code to write. ### Indirection — the HOW (mechanism / structure) > *To avoid direct coupling between two components, assign the responsibility of mediating between them to an intermediate object.* Key words: **between two components**. Indirection is structural. It is the most common *implementation technique* for Protected Variations — but it has other motivations that have nothing to do with predicted change: - **Breaking a dependency cycle**: A ↔ B becomes A → M ← B. - **Reducing an N×N mesh**: eight UI widgets that each know the other seven become eight widgets that each know one mediator (the Mediator pattern). - **Providing a hook point**: metrics, retries, authorization, caching, transaction demarcation applied once, in the middle. - **Enforcing a boundary for organizational reasons**: two teams agree on a contract object so they can deploy independently. So: *every Protected Variations solution built from a wrapper is an indirection, but not every indirection is a Protected Variations.* ### Pure Fabrication — the WHAT KIND (nature of the class) > *Assign a highly cohesive set of responsibilities to an artificial class that does not represent a concept in the problem domain, in order to support low coupling and high cohesion.* Key word: **does not represent a domain concept**. The domain of an online shop contains `Order`, `Customer`, `Invoice`. It does not contain `OrderRepository`, `OrderMapper`, `OrderController`, `PaymentGateway`, or `CheckoutCoordinator` — those are invented. Pure Fabrication is the explicit permission to invent them, instead of forcing `Order.saveToDatabase()` onto a domain object (which would be justified by a naive reading of Information Expert and would couple the domain to SQL/JDBC/ORM). Pure Fabrication is about **preserving cohesion of domain objects** and giving a home to mechanism-flavoured work. ## Putting them together on one example Requirement: an order must be persisted, and the storage technology may change. | Question | Principle | Answer for this example | |---|---|---| | Why are we adding anything at all? | **Protected Variations** | Storage technology is a predicted variation point; callers must not see it. | | What shape does the solution take? | **Indirection** | `OrderService` never calls the ORM/SQL client; it calls `OrderRepository`, which mediates. | | Is it legitimate for `OrderRepository` to exist even though "repository" is not a business word? | **Pure Fabrication** | Yes — it is an invented, highly cohesive class that keeps persistence out of `Order`. | | Why not put `save()` on `Order` itself, which knows its own data? | **Information Expert taken too literally** | Because it would drag persistence coupling into the domain and wreck `Order`'s cohesion. | ## Cases that separate them cleanly **Indirection without Protected Variations.** A `ChatRoom` mediator between `Participant` objects. There is no predicted variation being shielded; the point is to collapse a peer-to-peer mesh into a hub so participants don't reference each other. **Indirection without Pure Fabrication.** The mediating object is itself a genuine domain concept. In a trading system, an `Exchange` or `ClearingHouse` sits between `Buyer` and `Seller` and is a real business entity — indirection realized by a domain object, not a fabricated one. Likewise a `Broker` in an insurance domain. **Pure Fabrication without Indirection.** An invented `TaxCalculationPolicy` or `PricingEngine` that does not mediate between two parties at all — it simply gathers cohesive algorithmic work that fits no domain entity. **Protected Variations without a new class.** Sometimes the variation is protected by data-driven design (a lookup table, a config file, feature flags), by late binding in the language, or by a plug-in registry — no bespoke mediator class needed. ## Interview-grade summary sentence > Protected Variations names the *risk*; Indirection is the *shape of the fix*; Pure Fabrication is the *permission to invent the class that implements it*. The three collapse onto one artifact in the common case, which is exactly why you should be able to pull them apart on demand. ## Why the distinction matters practically If you cannot separate them, you produce two failure modes: 1. **Indirection with no Protected Variations rationale** — layers added "because clean architecture", with no named axis of change. Cost paid, benefit imagined. 2. **Protected Variations pursued by non-indirection means being overlooked** — you reflexively add a wrapper where configuration, a strategy passed as a parameter, or plain polymorphism would have been cheaper.