GRASP: Assigning Responsibilities

Object Design, Responsibilities and Patterns

Analysis (Parts I and II) told you what the system must do. Object design answers the next question: which software object does what? This section sets the scene: what object design starts from, what a "responsibility" is, and why naming design ideas as patterns helps.

Where object design starts

Object design does not start from a blank page. Each analysis artefact you met earlier hands the designer something specific, and the output for one scenario is called a use case realisation: the UP term for how one use case scenario is carried out in the Design Model by collaborating objects.

Even so, a design is not a one-to-one simulation of the real world. You may add classes that are not in the domain model, drop domain classes, and use different multiplicities. The Monopoly design below does all three kinds of thing; NextGen POS does the third, because the software Store creates just one Register.

The design also follows Model-View Separation: domain objects do not do output, and UI objects contain no application logic. So when the use case says "System displays total", the design only has to make sure that some object knows the total. Showing it is the UI's job.

Larman's underlying point is that UML is only notation. The real design tool is a mind trained in design principles, and GRASP gives those principles names.

Responsibilities: doing and knowing exam

A responsibility is not a method. It is an abstraction, and methods fulfil it. Its size varies a lot: "create a Sale" is one method, while "provide access to relational databases" might take a subsystem of hundreds of classes.

A method can fulfil a responsibility alone or by sending messages to other objects, which is called collaboration. For example, Sale.getTotal fulfils "know the sale total" by asking each SalesLineItem for its subtotal.

Responsibility-Driven Design (RDD)

In practice you decide responsibilities while drawing interaction diagrams (and while coding). There is no separate "assign responsibilities" document: every arrow you draw is a decision about who does what, and the design class diagram then records those decisions in its method compartments.

What a pattern is

Experienced designers keep reusing the same handful of good ideas. Writing those ideas down in a standard form, with a name, lets beginners use them too.

The name matters. It helps you hold the idea in memory, and it lets you describe a complex design in one sentence, such as "put a Facade over the persistence subsystem and use an Abstract Factory for the mappers".

The lecture lists five advantages of patterns:

• they capture expertise in a standard form that non-experts can use;
• that expertise is easy to re-use;
• they improve understandability;
• they give practitioners a common vocabulary;
• you can build new solutions by modifying existing patterns.

Because patterns codify old, proven knowledge, "new pattern" is an oxymoron. GRASP likewise introduces no new ideas: it names principles experts already use.

Larman's pattern format describes every pattern under the same headings. For each GRASP principle, the three you must be able to state are the Problem, the Solution and the Contraindications.

GoF refers to the 23 patterns of Design Patterns by Gamma, Helm, Johnson and Vlissides (the "Gang of Four", 1994), such as Adapter and Strategy (Part VI). The pattern idea itself came from Christopher Alexander's building architecture and was brought to software by Kent Beck and Ward Cunningham.

GRASP: the nine at a glance exam

The nine do not all do the same job. One is the root goal, two are the yardsticks you measure designs with, three tell you who gets a particular kind of responsibility, and three are mechanisms for reaching the goals.

Creator exam

Creating objects is one of the most common things an OO program does. If every class could create anything, you would get coupling everywhere. Creator gives a consistent rule for who creates, and the rule is chosen so that creating adds no new coupling.

How to apply it

B and A are software classes. Look first for existing design classes that fit the role of B. If there are none yet, borrow from the domain model (LRG) and mirror its containment in the design.

The reason it works is simple: the chosen creator is normally connected to the new object anyway, because it contains, records or uses it. Making it the creator therefore adds no new coupling.

The lecture works through the checklist for Monopoly's Square, which makes a good template for exam answers.

In the diagrams, Creator shows up twice: as a create message in the sequence diagram (the dynamic view) and, often, as composite aggregation in the DCD (the static view).

The standard examples

Each standard example is justified by one of the four criteria. In an exam answer, always name the criterion, not just the principle.

In Tony's Pizza the Order itself had no good domain creator (making the Customer create it felt wrong), so the controller's startOrder() creates it and records it as currentOrder.

Contraindications and benefits

Benefits: Creator supports Low Coupling, which means fewer maintenance dependencies and more reuse. Related: Low Coupling, Factory, Whole-Part.

Information Expert exam

A real design has hundreds of classes and thousands of responsibilities. You need a default rule for placing them that tends to produce designs that are easy to understand, maintain, extend and reuse. Information Expert ("Expert") is that rule.

Where to look: if suitable classes already exist in the Design Model, look there first. Otherwise look in the Domain Model and create a matching design class (LRG).

The procedure exam

Expert is the principle to consider first, unless the problem is a creation problem (use Creator) or a system-event problem (use Controller). Applying it takes four steps. Step through them for Larman's classic question, "who knows the sale total?"

The code follows the diagram line for line: each method is on the class that owns the data it uses.

public class Sale {
    private List<SalesLineItem> lineItems = new ArrayList<>();
    public Money getTotal() {                       // Sale knows all its line items
        Money total = new Money(0);
        for (SalesLineItem sli : lineItems) total = total.add(sli.getSubtotal());
        return total;
    }
}
public class SalesLineItem {
    private int quantity;
    private ProductDescription description;         // association to its description
    public Money getSubtotal() { return description.getPrice().times(quantity); }
}

Key ideas

Partial experts collaborate. When the information is spread across several objects, each does its part and they pass messages to share the work. The sale total needed three.

Expert supports Low Coupling. Put the responsibility anywhere other than with the information, and the information has to be shipped away from its home, which adds dependencies. The pair below makes that visible.

More course examples

Every Expert answer has the same shape: "X does it, because X has Y". The table collects the ones from the course.

When there are several partial experts, place the responsibility with the dominant expert, the one with most of the information. If no expert dominates, compare coupling and cohesion. If that is still a tie, consider likely future evolution (Monopoly's takeTurn, 4.10, is the worked case).

Contraindications exam

Benefits: Expert preserves encapsulation, because objects use their own information, and that usually gives Low Coupling. It also spreads behaviour over lightweight classes, which usually gives High Cohesion. Also known as: "Place responsibilities with data", "That which knows, does", "Do It Myself", "Put services with the attributes they work on".

Low Coupling and High Cohesion exam

Expert, Creator and Controller tell you where to try putting a responsibility. Low Coupling and High Cohesion are how you judge the result, and how you choose when two answers seem equally valid. They are a pair: Larman calls them "yin and yang", because a design that is bad on one is usually bad on the other.

Coupling

A class with high coupling suffers in three ways: it is forced to change when the classes it depends on change; it is hard to understand in isolation; and it is hard to reuse, because everything it depends on has to come along with it.

Five common forms of coupling from TypeX to TypeY exam

"Coupling" sounds vague until you can point to it in a diagram or in code. These are the five forms to recognise, each with a course example.

Worked comparisons

Low Coupling is used to choose between designs. Three comparisons from the course show how. First, Board versus an arbitrary Dog for getSquare in Monopoly.

Second, who computes a line's subtotal? ProductDescription knows the price, so Expert alone might pick it. But then Sale, when summing, would have to talk to ProductDescription as well: unnecessary coupling. Low Coupling therefore prefers SalesLineItem, which knows its quantity and its description.

Third, the comparison most often examined: who creates the Payment? Step between the two tabs and count the arrows in the dependency graphs.

Discussion and contraindications

Low Coupling is an evaluative principle that you apply to every design decision, and it cannot be considered in isolation from Expert and High Cohesion. Subclassing is strong coupling, so choose it carefully: a PersistentObject superclass that every domain class extends gives them persistence for free, but couples domain objects to a technical service and mixes architectural concerns.

There is no absolute measure of when coupling is "too high"; instead, ask whether increasing it will cause problems. Generic classes that are likely to be reused should have especially low coupling. And less is not always better:

Benefits: elements are unaffected by changes in other components, simple to understand in isolation, and convenient to reuse. Related: Protected Variations. Coupling and cohesion as design principles were identified by Larry Constantine.

Cohesion

A low-cohesion class does many unrelated things, or simply too much. It is hard to understand, reuse and maintain, and it is delicate: constantly affected by change. Such classes are often very coarse-grained, or have taken on work they should have delegated.

Levels of cohesion exam

Larman describes four levels, from very low to high. Notice that the remedy at the two lowest levels is to split the class.

Examples

Monopoly's playGame shows the difference between doing the work and delegating it.

In POS, having Register create Payment is harmless on its own. The point is the trend: if Register does part of the work for each of the ~50 system operations it receives, it becomes a bloated, incohesive object. Delegating Payment creation to Sale gives higher cohesion and lower coupling. (The library version of this argument, hasReachedLimit in the kiosk, is in 4.11.)

Benefits: clearer, easier-to-understand design; simpler maintenance and enhancement; Low Coupling is often supported; fine-grained, focused classes are easier to reuse.

Controller exam

When a cashier presses "End Sale", a window receives the click. Something in the domain must then actually end the sale. If the window did that work itself, the business logic would be stuck inside one UI technology. Controller decides which domain-side object receives each request from the UI.

Façade controller examples: Register (the POS terminal device), POSSystem, Store (root), MonopolyGame (root), Phone, BankCashMachine, ChessGame. Use case controllers are conventionally named <UseCaseName>Handler, …Coordinator or …Session: ProcessSaleHandler, PlayMonopolyGameHandler, OrderHandler. Use the same controller class for all system events in the same use case scenario, so it can keep that use case's state. (A session is one conversation with an actor, often organised as a use case session.)

Corollary: "window", "view" and "document" classes are not on the list. They receive UI events and delegate to a controller; they must not fulfil system operations themselves. Compare the two designs for enterItem.

In code, the window converts input and delegates; the controller coordinates without doing the work itself.

// UI layer: the window only converts input and delegates
public class ProcessSaleJFrame extends JFrame {
    private Register register;                      // reference to the domain-layer controller
    public ProcessSaleJFrame(Register register) { this.register = register; }
    private void onEnterItemClicked() {             // button click handler
        ItemID id = Transformer.toItemID(txtId.getText());
        int qty = Transformer.toInt(txtQty.getText());
        register.enterItem(id, qty);                // crosses from UI layer to domain layer
    }
}
// Domain layer: the controller coordinates, it does not do the work
public class Register {
    private ProductCatalog catalog;
    private Sale currentSale;
    public void makeNewSale()                     { currentSale = new Sale(); }                  // Creator
    public void enterItem(ItemID id, int qty)     { currentSale.makeLineItem(catalog.getProductDescription(id), qty); }
    public void endSale()                         { currentSale.becomeComplete(); }
    public void makePayment(Money cash)           { currentSale.makePayment(cash); }
}

Controller is a delegation pattern: it acts as a kind of façade onto the domain layer from the UI layer, and it should coordinate and do little itself. Tony's Pizza calls it a "postbox": its methods correspond to system operations and just call the right domain object.

Façade controller versus use-case controller exam

Larman chose Register for NextGen and MonopolyGame for Monopoly because each has only a few system operations (Monopoly has just two, initialize and playGame). In Tony's Pizza the presenter chose a use-case controller, OrderHandler, because one controller for the whole system (ordering, deliveries, ingredients) would get bloated.

Benefits, bloat and the cure

Benefits. (1) Reuse and pluggable interfaces: application logic is not bound to a window, so it can be reused, the UI can be replaced, or the system can run in batch mode. (2) You can reason about the state of the use case: for example, enforcing that makePayment cannot happen before endSale is easiest when one controller handles the whole use case.

Things not to confuse

• UI layer does not handle system events exam. That is why a JFrame, a web page or a main method must forward the event to a domain controller.
• GRASP controller ≠ Web-MVC controller. The MVC controller (for example a Struts Action) belongs to the UI layer and controls page flow. The GRASP controller belongs to the domain/application layer and does not know which UI technology is in use.
• UP terms: boundary objects are interface abstractions, entity objects are application-independent (often persistent) domain objects, and control objects are use-case handlers as in this pattern.
• In message-handling systems such as a telecom switch, each message is typically represented and handled by a Command object (GoF).

Related: Command; Façade (a façade controller is a kind of Façade); Layers; Pure Fabrication (a use-case controller is one). The lectures covered Controller only in workshop supplementary material (Workshop 4, Exercise 4; Tony's Pizza week 4), so the textbook (ch. 17.13) is the authority.

Polymorphism exam

Whenever behaviour depends on what kind of thing you have, the tempting design is an if or switch on its type. That works until a new kind arrives, and then every such conditional, often scattered across many classes, has to be found and edited. Polymorphism removes the conditionals.

Monopoly squares

Landing on Go gives you $200, Income Tax charges you tax, a Regular square does nothing, and Go To Jail moves you to jail. The types that vary are the kinds of square, and the varying operation is "what happens when a player lands", so it is named landedOn. Square types are domain concepts too, so the domain model gets a generalisation hierarchy as well.

// bad design (the corollary forbids this)
SWITCH ON square.type
  CASE GoSquare:        player receives $200
  CASE IncomeTaxSquare: player pays tax
  ...

public abstract class Square {
    public abstract void landedOn(Player p);       // {abstract}: no sensible default
}
public class GoSquare extends Square {
    public void landedOn(Player p) { p.addCash(200); }                        // Player is Expert on its cash
}
public class RegularSquare extends Square {
    public void landedOn(Player p) { }                                        // NO-OP avoids special-case logic
}
public class IncomeTaxSquare extends Square {
    public void landedOn(Player p) { p.reduceCash(Math.min(200, p.getNetWorth() / 10)); }
}
public class GoToJailSquare extends Square {
    private Square jail;                                                      // set at initialisation
    public void landedOn(Player p) { p.setLocation(jail); }
}

Design decisions in the dynamic model

Who sends landedOn? The Player, at the end of takeTurn: by Expert and Low Coupling, it already knows its location square. The player passes itself as a parameter, landedOn(p), which gives the square parameter visibility to the player, so it can send addCash, getNetWorth, reduceCash or setLocation, each assigned to Player by Expert.

Drawing polymorphic cases. You can draw a separate sequence diagram per subclass, or use sd/ref frames. The lecture and Tony's Pizza use an alt frame guarded by the runtime type, as below. That guard only documents which implementation runs; the code contains no type test.

RegularSquare.landedOn is an empty (NO-OP) method. It exists so that the client never has to special-case anything. The general guideline: declare the polymorphic operation {abstract} in the superclass unless there is a sensible default behaviour.

Refactoring for coupling. In iteration 1 the Piece knew the location, and Player kept asking it. When object A keeps needing B's data, either A should hold that data or B should have the responsibility (Expert). So in iteration 2 Player holds location directly, and Piece disappears from the design.

Other course examples

NextGen tax calculators. The third-party calculators (Tax-Master, Good-As-Gold TaxPro, …) have different interfaces: raw TCP socket, SOAP, Java RMI. Adapting differs by calculator type, so each adapter implements a polymorphic getTaxes(Sale): List<TaxLineItem> from the interface ITaxCalculatorAdapter. Each adapter is a local software object that calls its external calculator through that calculator's native API. (The full design is stepped through in 4.8.)

Tony's Pizza. Pizza and Drink both have getPrice(): double but compute it differently.

Library. When videos as well as books can be borrowed, an Item interface (getTitle, getDetail, getQuantity) is implemented by Book and Video, and getDetail is polymorphic.

When to design with interfaces

Use an interface when you want polymorphism without committing to a class hierarchy. With only an abstract superclass, every new implementation must subclass it, which is limiting in single-inheritance Java. A rule of thumb: for an abstract superclass C1, consider an interface I1 holding C1's public signatures and have C1 implement I1. That leaves an evolution point for future cases.

Benefits: new variations are easy to add, and new implementations can be introduced without affecting clients. Related: Protected Variations; many GoF patterns rely on polymorphism, including Adapter, Command, Composite, Proxy, State and Strategy (and Decorator).

Pure Fabrication and Indirection

Expert works when the information and the behaviour naturally belong together. Sometimes they don't: saving to a database, rolling dice for any game, or talking to an outside system. Forcing those jobs onto domain classes ruins their cohesion and coupling. These two principles give such jobs a home.

Pure Fabrication exam

Ideally the fabrication's design is very clean, or "pure"; the name also plays on the English idiom "pure fabrication", meaning something made up. On this page, invented classes are shaded green.

Example 1: saving a Sale exam

A real persistence framework uses many classes behind such a front-end façade (Part VI).

Example 2: rolling the dice (Cup)

In iteration 1, Player rolled and summed the dice. That had two problems: dice are general objects useful in many games, but the summing service was tied to Monopoly's Player; and you could not ask for the current total without rolling again. Every other domain-inspired class has the same problems (the slides note that by the domain model and Expert, MonopolyGame would be the candidate, which is acceptable but gives low cohesion). So the design fabricates a Cup that holds the dice, rolls them and knows their total. Larman still picks domain-flavoured vocabulary, since real games use dice cups.

public class Cup {                                   // not in the Monopoly domain model
    private List<Die> dice = new ArrayList<>();
    private int total;
    public void roll() {                             // command: changes state, returns nothing
        total = 0;
        for (Die d : dice) { d.roll(); total += d.getFaceValue(); }
    }
    public int getTotal() { return total; }          // query: can be asked without re-rolling
}

Example 3: the library's BorrowingHandler

In the library system, BorrowingKiosk is the controller that receives UI input. That leaves the question of who runs the application logic (newBorrowing, returnItem, getItemAvailability). With High Cohesion and Low Coupling in mind, none of the existing domain classes fits, so the design fabricates one.

You have already met other Pure Fabrications: use-case controllers, Factories (Part VI) and Adapters such as TaxMasterAdapter. In fact Larman says all GoF patterns are Pure Fabrications.

Representational versus behavioural decomposition

Pure Fabrication rests on a distinction between two ways of carving up a design.

Labelling a class "Pure Fabrication" is not important in itself. The point is that some classes come from the domain and some are invented for the designer's convenience.

Benefits: High Cohesion, because responsibilities sit in a fine-grained, focused class, and more potential for reuse. Related: Low Coupling, High Cohesion. A Pure Fabrication usually takes over a responsibility that Expert would have given to a domain class.

Indirection

Indirection is about decoupling: rather than letting two things depend on each other directly, put something in between them.

The standard examples

TaxMasterAdapter exam. The external Tax-Master system is reached over TCP sockets. If Sale talked to it directly, Sale would contain all the TCP code: it would depend on one specific protocol and system (high coupling) and mix sale and communication responsibilities (low cohesion). Instead, Sale asks an adapter.

• PersistentStorage mediates between Sale and the database, so it is both a Pure Fabrication and an Indirection.
• Library. Member sits between BorrowingKiosk and BorrowingRecord: the kiosk asks the member (hasReachedLimit, newBorrowing) rather than reaching the records itself. This intermediary is a domain class, not a fabrication.
• Controller. A controller is an indirection between the UI layer and the domain layer. A client-side controller also lets services be provided either locally or remotely.

Indirection versus Pure Fabrication

The lecture distinguishes them like this: Indirection means any class acting as an intermediary, whereas Pure Fabrication means an artificial, non-domain class. They overlap a great deal.

Discussion. The motivation for Indirection is usually Low Coupling. An old adage says most problems in computer science can be solved by adding another level of indirection; a counter-adage says most performance problems are solved by removing one. Many GoF patterns are specialisations of Indirection: Adapter, Bridge, Façade, Observer and Mediator.

Benefits: lower coupling between components. Related: Protected Variations, Low Coupling, Pure Fabrication.

Protected Variations exam

Some parts of a system are bound to change: an external API, a business rule, a hardware device. If the rest of the system depends on those parts directly, every change ripples outwards. Protected Variations (PV) is the root principle of GRASP: find the unstable spots and wall them off.

Points of change. A variation point is a variation in the existing system or current requirements, such as the several tax-calculator interfaces that must be supported now. An evolution point is a speculative variation that may arise in future but is not in the current requirements; in the UP these can be documented as Change Cases. PV applies to both.

Example: NextGen tax calculators exam

Applying PV takes two steps: find the instability, then build the stable interface. Here two mechanisms build it, Indirection and Polymorphism.

Library example. The requirement "a member may borrow videos as well as books" makes Book a known point of variation. PV puts a stable Item interface around it, and Polymorphism handles the type-specific behaviour (getDetail).

PV is the root principle

Data encapsulation, interfaces, polymorphism, indirection, standards, virtual machines, operating systems, configuration files: all are mechanisms for PV. The lecture summary: PV, Low Coupling and High Cohesion are the fundamental goals; the other six GRASP patterns are ways to achieve them. The mechanisms motivated by PV are these.

Liskov Substitution Principle (LSP) exam

Code written against a type T (an interface or abstract superclass) must keep working as expected when given any subtype or implementation S of T. Formally (Liskov 1988), S is a subtype of T if substituting an S object for a T object leaves the behaviour of every program written in terms of T unchanged. In the tax example, addTaxes must work whichever adapter it is passed:

public void addTaxes(ITaxCalculatorAdapter calculator, Sale sale) {
    List<TaxLineItem> taxes = calculator.getTaxes(sale);   // must work for EVERY implementation
}

Law of Demeter: "Don't Talk to Strangers" exam

This was one of the nine GRASP patterns in Larman's first edition. It was replaced by the more general PV because it is a special case of it: protection against changes in object structure. Within a method, send messages only to:

1. this (self);
2. a parameter of the method;
3. an attribute of this;
4. an element of a collection that is an attribute of this;
5. an object created within the method.

Those objects are the familiars; objects reached indirectly are strangers. Traversing long paths couples the client to how objects are connected, and the further the path, the more fragile the code.

class Register {
    private Sale sale;
    void slightlyFragile() {
        Money amt = sale.getPayment().getTenderedAmount();               // talks to a stranger (Payment)
    }
    void moreFragile() {
        AccountHolder h = sale.getPayment().getAccount().getAccountHolder(); // even further
    }
    void conforming() {
        Money amt = sale.getTenderedAmountOfPayment();                   // familiar hides the structure
    }
}

To obey the law strictly, you add operations to the familiars that return the desired information and hide how they got it. That isn't always worth it: structure in stable libraries (Java's) or in mature systems seldom changes. It matters most in young systems, where the structure is still changing.

PV, information hiding and the Open-Closed Principle

These are essentially the same idea under three names.

• Information hiding (Parnas 1972) means hiding design decisions that are difficult or likely to change from other modules. It is not a synonym for data encapsulation, which is only one technique for it.
• The Open-Closed Principle (Meyer): modules should be open for extension (adaptable) and closed to modification that affects clients. "Closed with respect to X" means clients are unaffected if X changes. A class with private fields and public accessors is closed with respect to its field definitions but open to changing them; the tax adapters are closed with respect to their public interface (ITaxCalculatorAdapter) but open to private changes as external APIs evolve. "Module" means any software element: method, class, subsystem or application.

PV itself was named as a pattern by Cockburn (1996), but the idea is decades older.

Contraindications: speculative PV exam

Protecting an evolution point can cost more than simply reworking a simple, "brittle" design when the change actually comes. Larman's examples are an unneeded scripting interpreter in a pager system, and his own early "generalize-itis" of writing superclasses for future cases that never arrived.

Benefits: new variations are easy to add; new implementations don't affect clients; coupling is lowered, and so are the impact and cost of change. PV is related to almost every principle and pattern (polymorphism, interfaces, indirection, encapsulation, most GoF patterns). Pree calls variation and evolution points "hot spots".

How the Principles Fit Together

You have now met all nine. They are not independent rules: some are means to others, and some regularly disagree. This section maps how they relate, collects the standard conflicts, and links GRASP to the GoF patterns of Part VI.

The relationship map

The lecture shows the relationships as a diagram in which each arrow means "is a way to achieve".

Conflicts and trade-offs exam

Principles often disagree, and the exam rewards naming the conflict and saying how it was resolved. Read each row from the two competing principles across to the resolution, and notice how often the deciding factor is cohesion, coupling or stability.

GRASP and the GoF patterns exam

The GRASP principles generalise the GoF patterns, so each GoF pattern can be described in GRASP terms. This is also how mixed GRASP/GoF multiple-choice options are built.

Worked Use-Case Realisations (Larman ch. 18) exam

Larman's chapter 18 puts all the principles to work on complete use cases. This is exactly what an exam design question asks you to do: take a system operation and draw the design sequence diagram, justifying each message. Here is the general procedure, then NextGen POS and Monopoly.

The procedure for designing a system operation

1. Take the system operation from the SSD. By Controller, choose the domain object that receives it, and draw the found message into that object.
2. Work through the operation contract postconditions (Part II). An instance creation calls for Creator. An association formed is usually done by the creator, or by whoever has visibility. An attribute modification calls for Expert: the object that owns the attribute.
3. For every other responsibility, state it as a question ("Who knows X?") and apply Expert. Tabulate the information needed against the classes that have it.
4. Evaluate the alternatives with Low Coupling and High Cohesion, and then with future evolution (PV).
5. If Expert's choice hurts cohesion or coupling (technical services, generic behaviour), use Pure Fabrication or Indirection. If behaviour varies by type, use Polymorphism.
6. Check visibility for every message: attribute, parameter, local or global (Part III).
7. Ignore display and output (Model-View Separation); just make sure the information is known.
8. Design Start Up last. Once you know what must exist, pick an initial domain object at or near the root of the containment hierarchy (Store, MonopolyGame). It creates its children by Creator.
9. Annotate messages with the principle used ("by Creator", "by Expert", …) and update the DCD.

NextGen POS: Process Sale

The controller is Register, a façade device controller. That is reasonable because there are only four system operations: makeNewSale, enterItem, endSale and makePayment. (In UML the system operation is a found message arriving from outside the diagram, drawn from a filled dot.)

Putting the four operations together gives this design class diagram. Every method in it was put there by one of the decisions above.

Connecting the UI to the domain

In main, you create the initial domain object Store, get its Register, and pass that to the window: new ProcessSaleJFrame(store.getRegister()). Alternatively the UI gets the domain object from a factory. To show the running total, the UI has two options. It can ask the Register, which keeps UI coupling lower but makes Register bigger and less cohesive. Or it can get the Sale and ask it directly: more coupling, but acceptable because Sale is stable. Larman takes the second option.

Monopoly: Play Monopoly Game

Here the controller is MonopolyGame, a root-object façade, which works because there are only two system operations. The design proceeds in three decisions.

The game loop. The loop is "for N rounds: for each player p: p takes a turn". By Expert, MonopolyGame runs it, because it knows the round count (LRG) and all the players. A private helper playRound() keeps the methods cohesive and uses domain vocabulary.

Who takes a turn? This is the course's main example of partial experts with none dominant.

Inside takeTurn. Die rolls itself, by Expert, since it changes its own faceValue. Board.getSquare(oldLoc, fvTot) finds the new square, by Expert, since Board knows all the Squares. The Piece (or Player) updates the location. Player coordinates all of this, so it needs permanent visibility to the dice, Board and Piece, set up at Start Up.

Monopoly Start Up. MonopolyGame creates the Board and the Players (and the dice or the Cup), and Board creates the 40 Squares, all by Creator. Larman shows this compactly with «create» dependencies in a class diagram.

Course Examples and Workshop Solutions

The lectures and workshops apply the same reasoning to three more systems. They are worth knowing because exam questions are built the same way: a small domain, then "who should do X, and why?".

The Library Borrowing System (lectures, weeks 4–5)

The lectures ask a sequence of design questions about it:

• Who creates a BorrowedItem? BorrowingRecord, by Creator: it contains (compositely aggregates) them.
• Who checks whether a member has reached the borrowing limit? Member.hasReachedLimit(), by Expert: Member has borrowLimit and is associated with its records.
• Why not BorrowingKiosk or BorrowingRecord? Both are acceptable, but each costs more, as the graphs show.

• The kiosk is the controller; who does the application logic? No domain class fits without hurting High Cohesion or Low Coupling, so use the Pure Fabrication BorrowingHandler (drawn in 4.7). The kiosk keeps the UI-facing memberLogin, listItem, returnItem and newBorrowing, and delegates.
• Future: videos as well as books. Apply PV at the known variation point Book, with a stable Item interface (getTitle, getDetail, getQuantity) implemented by Book and Video. getDetail is polymorphic, and BorrowingItem refers to Item.

The lecture's closing note: several designs can satisfy GRASP, so use Low Coupling and High Cohesion to choose between them.

Workshop 4: online marketplace

The domain has User, Listing, Item, Category, SubCategory, Bid, Transaction, Message, Photo and Address. The partial solution reasons as follows.

Controller. The controllers offer createListing(...) and makeBid(...), taking all the user input as parameters. Use one controller if Listing owns both behaviours; if the behaviours are split between Listing and User, use two use-case controllers, which keeps cohesion and separates concerns. The workshop's lesson: GRASP principles are not mutually exclusive, and every choice is a trade-off you must justify.

Workshop 5: Mobile Service Terminal (MST) POS

The indicative solution maps onto GRASP like this.

The worksheet stresses iterating: dynamic modelling reveals missing methods and attributes, so you update the DCD to match.

Tony's Pizza (weeks 4–5) is covered under each principle: Creator (4.2), Expert (4.3), the OrderHandler use-case controller (4.5) and the Item.getPrice() polymorphism (4.6).

Exam Toolkit exam

This last section turns the Part into exam technique: a cheat sheet for the multiple-choice questions, a template for written justifications, and the mistakes that cost marks.

Decision cheat sheet for MCQs

Match what the question stem describes to the left column. Several rows warn that a more specific GoF pattern beats the nearest GRASP answer.

The tie-break rule

The options mix GRASP and GoF names, so decide first which family the stem is about.

Past-exam MCQs. All 20 items from 2021 are worked in Part IX. The GRASP ones are S1 Q1.1 (Low Cohesion), S2 Q1.1 (Polymorphism, per the official answer), S2 Q1.2 (Controller), S2 Q1.5 (Information Expert) and S2 Q1.10 (Controller).

How to justify a design choice in writing

A justification earns marks when it names the principle and gives specific evidence. Build each one from these parts.

Model justifications in that style:

On diagrams, label messages and classes with the principle ("by Creator", "by Expert", "by Polymorphism"), as Larman and the lecturers do. The project rubrics (written by the same teaching team) reward "correct identification of design concerns using GRASP" and justification with specific references to classes, methods and responsibilities. They also say that a well-justified design based on correct principles is sufficient: it need not be "the best". Vague "this is good design" statements earn nothing.

Common mistakes