GRASP — Responsibility Assignment Patterns

Explore Topics

🗺

Introduction

Whose job is it, anyway?

⚖️ GRASP Decision Theater — Whose Job Is It?

0 / 7 cases solved

Information Expert

Who should be responsible for computing Sale.getTotal()?

A Sale holds a list of SalesLineItem objects, each referencing a Product (price) and a quantity. A Register holds a reference to the currentSale. The grand total is needed for the receipt.

🗺

Introduction

Whose job is it, anyway?

GRASP — General Responsibility Assignment Software Patterns — is Craig Larman's answer to the question SOLID leaves on the table: once you have decided to use small focused classes, WHICH class gets which responsibility? Larman lays out nine principles, each a tested answer to a recurring assignment question. Five are foundational (Information Expert, Creator, Controller, Low Coupling, High Cohesion); four handle "what if the obvious answer is not good enough?" (Polymorphism, Pure Fabrication, Indirection, Protected Variations). The running domain throughout this topic is Larman's canonical Point-of-Sale system: Sale, SalesLineItem, Product, Register, Payment, NewSaleController — chosen because every GRASP principle has a clean question to answer about it.

Key Ideas

Larman, "Applying UML and Patterns" — 1st ed. 1997, current 3rd ed. 2004
GRASP = General Responsibility Assignment Software Patterns
5 core principles: Information Expert, Creator, Controller, Low Coupling, High Cohesion
4 advanced principles: Polymorphism, Pure Fabrication, Indirection, Protected Variations
SOLID and GRASP COMPLEMENT each other — SOLID is "how to shape", GRASP is "who gets what"
GRASP is the conceptual bridge from UML responsibility assignment to GoF design patterns

Strengths

✦Gives a name and a defense to every responsibility assignment decision
✦Ties directly to UML sequence diagrams — the place where assignment happens visually
✦Aligns with most GoF patterns (Controller, Factory, Adapter, Strategy are GRASP applied)
✦Vocabulary makes design code review concrete instead of subjective

Weaknesses

△Less famous than SOLID — fewer one-line slogans, harder to remember off the cuff
△Some principles (Polymorphism, Pure Fabrication) overlap with GoF patterns and SOLID
△"Protected Variations" is hard to apply prematurely — it asks "what will change?" honestly
△Larman's textbook is dense; the principles are easier to teach than to internalize

Used in:Most enterprise Java codebases organize themselves around GRASP without naming it. Spring's service layer = a Controller-Information Expert split. Repository classes are Pure Fabrications. Hexagonal Architecture (Cockburn) is Indirection + Protected Variations at system scale. When you read "Factory" in the GoF book, you are reading the Creator principle with a specific implementation.

Code Snippets

Quiz

Introduction Quiz

QUIZ 1/8

What is the central question GRASP is designed to answer?

Diagrams

GRASP Map — Each principle, the question it answers

Loading diagram...

Point-of-Sale Domain — the playground for every GRASP question

Loading diagram...

Information Expert — total() walks its line items

Loading diagram...

Practice

Drag each responsibility / smell onto the GRASP principle that assigns it (or the principle it violates).

EXERCISE 1/5

compute Sale's total

create a new SalesLineItem

handle the GUI "endSale" click

expose a CLI on the same orchestration

cut Register's field count from 4 to 1

split god-Register into focused classes

remove `switch (paymentType)` from Sale

invent SaleRepository to hold save()

wrap the foreign GovTaxService API

add ITaxCalculator interface shielding Sale

Information Expert

Creator

Controller

Low Coupling

High Cohesion

Polymorphism + Pure Fabrication

Indirection + Protected Variations

Spot the responsibility misassignment

EXERCISE 2/5

Click on the line you think contains the bug, then press Confirm.

1class Register {

2 Sale currentSale;

4 double computeTotal(Sale s) { // <-- WRONG OWNER

5 double total = 0;

6 for (SalesLineItem li : s.getLineItems()) {

7 total += li.getProduct().getPrice() * li.getQuantity();

8 }

9 return total;

10 }

11}

13class Sale {

14 private List<SalesLineItem> lineItems;

15 List<SalesLineItem> getLineItems() { return lineItems; } // leaks internals

16}

Common GRASP misconceptions

EXERCISE 3/5

Information Expert means putting ALL of the logic in one "expert" class.

Pure Fabrication contradicts "use domain classes" and is therefore an anti-pattern.

A Controller class should also render the UI it receives events from.

GRASP and SOLID conflict — you should pick one set of principles.

Low Coupling means a class should have ZERO direct dependencies.

Protected Variations is OCP under a different name.

Refactor Sale to satisfy Protected Variations

EXERCISE 4/5

// ── Before: violates Indirection + PV ──
class BadSale {
    private final GovTaxService gov = new GovTaxService();
    double totalWithTax(double subtotal) {
        return subtotal * (1 + gov.computeTaxRate("IL", "book"));
    }
}

// ── After: Protected Variations + Indirection ──
 TaxCalculator {
    double rate(String region, String category);
}

class GovTaxAdapter  TaxCalculator {
    private final GovTaxService gov = new GovTaxService();
    public double rate(String region, String category) {
        return gov.computeTaxRate(region, category);
    }
}

class Sale {
    private final  tax;

    Sale( tax) {
        this.tax = ;
    }

    double totalWithTax(double subtotal) {
        return subtotal * (1 + tax.rate("IL", "book"));
    }
}