Responsibility Assignment (GRASP)

The running example: an e-commerce Order

We'll use Larman's classic point-of-sale shape. An Order contains a list of OrderLine objects; each OrderLine references a Product and a quantity. There's a UI Window where the cashier clicks, and somewhere a Checkout use case fires. The question every principle answers is the same: given a new job, which of these classes should own it?

Information Expert — give the job to whoever has the data

The most-used GRASP principle: assign a responsibility to the class that has the information needed to fulfill it. Who should compute the order's grand total? The Order holds the list of lines, so the Order is the expert — it sums its lines. But each line's subtotal depends on a price and a quantity that live on the OrderLine, so each OrderLine computes its own subtotal. The work flows to where the data already is, and no one has to reach across object boundaries to peek at someone else's internals.

// ❌ BAD: the Controller is NOT the information expert.
// It reaches into the order's internals, then into each line's internals.
class CheckoutController {
  grandTotal(order: Order): number {
    let total = 0;
    for (const line of order.lines) {          // poking at Order's internals
      total += line.product.price * line.qty;  // poking at OrderLine's internals
    }
    return total; // logic that depends on Order/OrderLine data lives OUTSIDE them
  }
}

// ✅ GOOD: Information Expert — the data owner computes its own answer.
class OrderLine {
  constructor(private product: Product, private qty: number) {}
  subtotal(): number { return this.product.price * this.qty; } // it has the data
}
class Order {
  private lines: OrderLine[] = [];
  total(): number {                                  // Order has the lines…
    return this.lines.reduce((sum, l) => sum + l.subtotal(), 0); // …so Order sums them
  }
}

Notice the payoff: in the good version, change how a line is priced (add a discount, a tax band) and you edit OrderLine only — the Order and the controller don't move. In the bad version, that pricing logic leaked into the controller, so a pricing change drags the controller along with it. Information Expert produces low coupling and high cohesion as a side effect — which is exactly why it's the workhorse.

Creator — who should make a new object?

When something needs to be instantiated, Creator says: assign creation to the class that contains, aggregates, records, or closely uses the new object — and that has the data to initialize it. Who creates a new OrderLine? The Order does: it contains the lines, and it has (or is handed) the Product and quantity needed to build one. The UI Window shouldn't new OrderLine(...) and then hand it over; that scatters construction logic and couples the UI to the line's constructor.

class Order {
  private lines: OrderLine[] = [];
  // Creator: the container that aggregates OrderLines is the one that makes them.
  addLine(product: Product, qty: number): void {
    this.lines.push(new OrderLine(product, qty)); // Order owns its parts
  }
}

Controller — who receives a system event?

When a system event arrives from the outside (the cashier clicks checkout), Controller says: route it to a non-UI object that represents either the overall use case (a CheckoutHandler, a use-case controller) or the system/root object (a façade controller). The point is to keep the UI thin — the window captures the click and immediately delegates — so business logic never gets tangled into buttons and views. A bloated controller that does everything, though, is an anti-pattern; the controller should coordinate, then delegate the real work to the experts.

Low Coupling & High Cohesion — the evaluative pair

These two aren't about a specific job — they're the scorecard you hold up to any candidate assignment. Low Coupling: prefer the assignment that creates the fewest, thinnest dependencies between classes. High Cohesion: prefer the assignment that keeps each class focused on one set of related responsibilities. When two placements both seem plausible, pick the one that keeps both dials healthy. Information Expert usually wins on this scorecard automatically — putting the logic next to its data is what keeps coupling low and cohesion high.

The remaining five, in one line each

• Polymorphism — when behavior varies by type, assign the variation to subtypes via a polymorphic operation instead of if/else/switch on a type tag (e.g. each PaymentMethod charges itself).
• Indirection — assign a responsibility to an intermediate object so two things don't couple directly (a mediator/adapter sitting between them).
• Pure Fabrication — when no domain class is a good home, invent a made-up class that doesn't represent a real-world concept (e.g. a OrderRepository or TaxService) to keep coupling low and cohesion high.
• Protected Variations — wrap an unstable point (a third-party API, a changing rule) behind a stable interface so variation on one side can't ripple to the other.
• Indirection + Pure Fabrication + Protected Variations together are how you tame the messy parts the pure domain model can't absorb cleanly.

When to reach for GRASP

Use GRASP whenever you're staring at a method and unsure which class it belongs on — during design, in code review, or mid-refactor. The trigger questions are concrete: Does this logic reach into another object's fields to do its job? (move it to the Information Expert). Is the UI doing business work? (introduce a Controller). Is a class creating something it doesn't contain or use? (revisit Creator). Does no domain class feel like the right home? (consider a Pure Fabrication). GRASP turns the vague "this feels off" into a named force you can argue about.