Design Patterns II: Strategy to Observer

Strategy exam

This Part continues the catalogue of Gang of Four (GoF) patterns that Part VI began with Façade, Decorator, Builder, Adapter, Factory and Singleton. Every pattern here is drawn with the same colour code, so before we start, here is what the colours mean. Once you know it, you can glance at any diagram on the page and see at once which box plays which part.

Strategy solves a very common problem: the same thing can be calculated in several different ways, and the choice of way changes. A shop prices a sale differently for seniors, on Mondays, or during a promotion. If all those rules live inside one class as a big if/switch, that class has to be edited every time a rule changes. Strategy pulls each rule out into its own small class.

How to spot it in a scenario

Strategy is a behavioural pattern: it is about how responsibility for an algorithm is shared between objects. The give-away in an exam stem is a list of different ways to do the same job: to calculate, price, discount, tax, score, analyse, assign, route or sort. Another tell is a policy that depends on something like membership level, customer type, time of day, day of the week or country. Look for these phrases too:

• "the rules change frequently";
• "a large conditional that switches between variants of the same algorithm" (workshop 9);
• a need to "swap the behaviour at run time";
• a plan to "plug in new algorithms later, such as an ML engine".

The two tabs below show the same pricing problem first as a switch inside Sale, then as Larman's Strategy design.

Participants and structure

Strategy has three core roles, plus a factory that usually travels with it.

• The Strategy is an interface declaring the algorithm's operation.
• Each ConcreteStrategy implements one version of the algorithm.
• The Context holds an attribute typed to the interface and delegates to it. It usually passes itself (this) as an argument, so that the strategy has parameter visibility back to the context; Larman says this is "usually required".
• Strategies are usually created by a Factory, often a Singleton. Workshop 9 puts it this way: Strategy "is often used in combination with the Factory pattern to determine which algorithm to use."

The textbook example in code

Here is Larman's pricing design in Java. Compare each line with the "With the pattern" diagram above: the interface, the two realising classes, and the Sale holding one field of the interface type.

public interface ISalePricingStrategy { double getTotal(Sale s); }

public class PercentDiscountPricingStrategy implements ISalePricingStrategy {
    private double percentage = 0.05;
    public double getTotal(Sale s) { return s.getPreDiscountTotal() * (1 - percentage); }
}
public class AbsoluteDiscountOverThresholdPricingStrategy implements ISalePricingStrategy {
    private double threshold = 50, discount = 5;
    public double getTotal(Sale s) {
        double pdt = s.getPreDiscountTotal();
        return pdt >= threshold ? pdt - discount : pdt;
    }
}
public class Sale {                                         // Context
    private ISalePricingStrategy pricingStrategy =
        PricingStrategyFactory.getInstance().getSalePricingStrategy();   // created by a Factory
    public double getTotal() { return pricingStrategy.getTotal(this); }  // delegate, passing this
    public void setPricingStrategy(ISalePricingStrategy ps) { pricingStrategy = ps; }   // swap at run time
}

Three lines in Sale carry the whole pattern. The field is declared with the interface type. getTotal() simply delegates, passing this. And setPricingStrategy lets the rule be swapped while the program runs, something a switch on a type code cannot do without editing the class.

Where the strategy comes from: the factory

Somebody still has to decide which strategy a Sale gets. In Larman's POS (section 26.7) that job belongs to a Singleton PricingStrategyFactory, with operations getSalePricingStrategy() and getSeniorPricingStrategy(). It reads the name of the strategy class from a property and instantiates it reflectively, so the pricing policy can change while the system is running. For the same reason it deliberately does not cache the strategy it creates. It also reads the percentage values from an external store, so the numbers can change without a code change.

The course's other Strategy examples

The course uses Strategy in three main examples, and it has come up repeatedly in past exams. Larman's pricing is the first. The second is Tony's Pizza delivery assignment (week 8), which decides who or what delivers an order. The Strategy interface is IAssignmentStrategy.assignResource(order: Order): IDeliveryResource. The Order is the context object passed in: it knows its priority, its number of line items, and its restaurant, which leads to the delivery fleet. Both concrete strategies build DroneComposites when they need a team of drones (you will meet that in 7.2).

The third example, Monopoly Express (workshop 9), uses three interchangeable scoring rules and combines Strategy with Composite. It is worked in full, with the official partial solution, in 7.3.

Why it works: the GRASP behind it

Pitfalls and trade-offs

• The selection logic does not disappear. It moves into the factory or the client. Strategy removes the switch from the context, not from the system.
• There are more objects to create and understand.
• The strategy often needs data from the context, and passing this couples the strategy to the context. Larman's idiom is to pass the aggregate object (the whole Sale) rather than pieces of it.
• A uniform interface may hand some strategies data they don't need.
• Don't apply it to two trivial variants that will never change. That is "pattern-itis": the design gets heavier with nothing gained.

Composite exam

Many things in software are made of smaller things of the same kind: a picture is made of shapes and other pictures, a fleet of vessels and smaller fleets, an expression of sub-expressions. Code that works on such structures usually has to ask "is this one thing or a group?" at every level. Composite removes that question by giving the group and the single item the same interface.

How to spot it in a scenario

Composite is a structural pattern. The clearest sign is a part–whole, tree, recursive or nested structure, and the course is full of them: a house containing rooms that contain units, a building with people and the objects they carry, a picture made of shapes, a fleet of vessels, a quadtree divided into quadrants, an expression built from sub-expressions, a team of drones, an army of characters, and a menu with submenus. The wording of a scenario also gives it away. Watch for:

• a requirement to "apply a property or operation to the whole, to some parts, or to one item, in the same way";
• "the client shouldn't care whether it has one or many";
• a need to "aggregate a result over the parts" (a total, count or minimum);
• "several conflicting policies combined so they look like one".

Participants and structure

The pattern has four roles.

• The Component is an interface or abstract class. It declares operation(), and possibly the child-management operations.
• A Leaf has no children and does the real work. There can be several leaf types.
• The Composite holds 0..* children typed as Component. Its operation() iterates over the children and combines their results, and it provides add, remove and getChild.
• The Client uses only Component.

Larman sums up the signature feature: "the outer composite object contains a list of inner objects, and both the outer and inner objects implement the same interface."

The lecture example in code

In the lecture's shapes example, Picture is the composite. It draws itself by delegating to its children, and it neither knows nor cares whether a child is a circle or another picture.

public abstract class Shape { public abstract void draw(); }
public class Circle extends Shape { public void draw() { /* draw circle */ } }      // Leaf
public class Picture extends Shape {                                               // Composite
    private final List<Shape> shapes = new ArrayList<>();
    public void addShape(Shape s) { shapes.add(s); }
    public void draw() { for (Shape s : shapes) s.draw(); }    // delegate to the children
}

What happens at run time: recursion

The class diagram is static; the interesting part of Composite happens when the operation runs. A call on the root fans out to the children, a composite child repeats the same call one level down, and the answers are combined on the way back up. The stepper traces this on the quadtree from the 2021 exam (Q9, 7.11): Black.countBlack() returns size * size, White and Outside return 0, and Divided.countBlack() returns the sum of its four children.

Safety versus transparency exam

The main design decision is where to declare the child-management operations, add and remove. There are two choices, and each gives something up.

• Transparency means declaring them in Component. All nodes then look the same, but Leaf must implement meaningless operations, either by throwing UnsupportedOperationException or by ignoring the call.
• Safety means declaring them only in Composite. Misuse is then caught at compile time, but a client must know it has a Composite before it can add children.

Other design decisions and pitfalls

• An abstract composite superclass can hold the child list, so that subclasses differ only in how they combine the results (min or max, for example). You will see this in Larman's pricing design in 7.3.
• Parent references are optional.
• You must prevent cycles: a picture that contains itself would recurse for ever.
• Restricting what can be a child (for example, "a fleet contains only vessels") is hard when children are typed as Component, so use narrower types or run-time checks.
• Recomputing aggregates over large trees can be slow, so cache the values if needed.
• The design can become overly general.

More course examples

The course uses Composite in several more places. In the lecture's Disney Army, Army implements IDisneyAdapter and aggregates 0..* IDisneyAdapter, so army.move() moves every member (the character adapters are from Part VI). Tony's Pizza (week 8) has a DroneComposite that implements IDeliveryResource alongside DeliveryStaff and single drones. Monopoly Express's CompositeRule and Larman's composite pricing strategies are covered in 7.3.

GRASP. Composite is based on Polymorphism. It gives PV for the client, which is unaffected by whether it holds an atomic or a composite object. It is often used together with Strategy (next section), and with Command (a macro command is a Composite of commands, 7.6).

Strategy and Composite Together: Composite Strategies

Strategy lets a context hold one interchangeable policy. But what if several policies apply at once and must be reconciled? Composite answers that: make a "group of strategies" that is itself a strategy. The context still holds one object, and has no idea that behind it sits a whole set of rules. The course uses this combination twice, in Larman's pricing and in Monopoly Express, and it reappears in the 2021 exam code (7.10).

The problem: several pricing policies at once

A store may have several policies in force on the same day:

• a 20% senior discount;
• 15% off for preferred customers on sales over $400;
• $50 off purchases over $500 on Mondays;
• 15% off everything if you buy a case of Darjeeling tea.

Different policies are triggered by different things: the customer type, the time period, or the product on a line item. When several apply, a conflict-resolution policy decides the outcome, either best for the customer (the lowest price) or best for the store. Throughout, the Sale should not know whether it holds one strategy or many, which is exactly what Composite gives it.

public abstract class CompositePricingStrategy implements ISalePricingStrategy {   // abstract Composite
    protected List<ISalePricingStrategy> strategies = new ArrayList<>();
    public void add(ISalePricingStrategy s) { strategies.add(s); }
    public abstract double getTotal(Sale sale);
}
public class CompositeBestForCustomerPricingStrategy extends CompositePricingStrategy {
    public double getTotal(Sale sale) {
        double lowest = sale.getPreDiscountTotal();
        for (ISalePricingStrategy s : strategies) lowest = Math.min(lowest, s.getTotal(sale));
        return lowest;                                   // CompositeBestForStore would use max
    }
}

Notice the design decision from 7.2 at work: the abstract composite superclass holds the child list and add(), so its subclasses differ only in how they combine the children's answers (Math.min here, max for the store).

Creating the composite

Who builds this structure, and when? Larman's answer (Figs. 26.17–26.19) uses the factory from 7.1 and adds strategies at three points:

1. when the sale is created, the current store discount is added;
2. a new system operation, enterCustomerForDiscount(custID), adds the customer-type discount;
3. when a product is entered, a product-type discount is added.

The stepper walks through the first two, which Larman draws in full.

Monopoly Express: three scoring rules, best one wins

Workshop 9's game has three scoring rules, and they are interchangeable strategies:

• Rule 1, applied every turn, scores complete groups.
• Rule 2, applied every 2nd turn, scores the incomplete group with the highest dice total.
• Rule 3, applied every 3rd turn, scores the sum of all placed faces.

Only the best applicable rule counts. So a factory picks the rules applicable to the turn number and puts them in a composite "highest score" strategy, which is the same design as CompositeBestForCustomer. The official partial solution to Workshop 9 (Q1.1 and Q1.2) confirms this design. In its words, the strategy pattern should be used to implement the rules, the composite pattern should be used to calculate the score when several rules apply, and the main class should use the singleton factory to determine which rules apply, based on the number of turns.

Its roles in detail:

• ScoreRule is the «interface» with getScore(board : BoardGame) : int: the Strategy interface and, at the same time, the Composite's Component.
• CompleteGroupRule (Rule 1), IncompleteGroupRule (Rule 2) and AllGroupRule (Rule 3) are the concrete strategies and the leaves. CompleteGroupRule also has a helper, getGroupValue(group : String) : int, which looks up a group's money points.
• CompositeRule realises ScoreRule too. It holds -rules : ArrayList<ScoreRule>, drawn as an association with role -rules and multiplicity 1..* back to the interface, and offers add(r : ScoreRule). Its getScore asks each contained rule for its score and keeps the highest.
• RuleFactory is a «singleton», with a static instance and a static getInstance(); its getRule(p : Player) : ScoreRule returns the rule to use for that player's current turn.
• MonopolyExpress, which holds the static main, «use»s RuleFactory and Player, and the provided Dice and Board packages (and Board uses Dice).

Observer / Publish–Subscribe / Delegation Event Model exam

Often one object changes and several others need to know: a window must show the new total, a log must record the change, a customer must get an email. Wiring the changing object directly to all of them couples it to every one, including classes in other layers. Observer turns this around: interested objects subscribe, and the changing object just tells "whoever is subscribed".

One pattern, many names

The pattern and its roles go by several names, and an exam may use any of them.

How to spot it in a scenario

The basic cue is a requirement to "inform interested parties as soon as something changes or happens", especially when there are "consumers interested only in particular sports, teams or events". In user interfaces it shows up as "the GUI must refresh when the model changes, but the model must not know the UI", or as "handle button-press events". Other cues are "log or audit every state transition", "subscribe and unsubscribe at run time", and "the number and kinds of interested objects vary".

Participants and structure

• The Subject keeps a list of observers typed to the interface. It offers addObserver (subscribe), removeObserver (unsubscribe) and notifyObservers (publish).
• The Observer interface declares update(…).
• The ConcreteSubject and the ConcreteObservers are the concrete classes, and each ConcreteObserver reacts in its own way.

Larman's example: the Sale and its window

Larman makes the Sale the publisher and a GUI window, SaleFrame1, the subscriber. You saw the class diagram in the "With the pattern" tab; here is the interaction and the code.

public interface PropertyListener { void onPropertyEvent(Object source, String name, Object value); }

public class Sale {                                                   // Publisher
    private final List<PropertyListener> propertyListeners = new ArrayList<>();
    private Money total;
    public void addPropertyListener(PropertyListener lis)    { propertyListeners.add(lis); }
    public void removePropertyListener(PropertyListener lis) { propertyListeners.remove(lis); }
    public void setTotal(Money newTotal) { total = newTotal; publishPropertyEvent("sale.total", total); }
    private void publishPropertyEvent(String name, Object value) {
        for (PropertyListener pl : new ArrayList<>(propertyListeners))   // copy: safe if the list changes
            pl.onPropertyEvent(this, name, value);
    }
}
public class SaleFrame1 extends JFrame implements PropertyListener {  // Subscriber
    private final JTextField saleTextField = new JTextField();
    public void initialize(Sale sale) { sale.addPropertyListener(this); }      // subscribe
    public void onPropertyEvent(Object source, String name, Object value) {
        if (name.equals("sale.total")) saleTextField.setText(value.toString());
    }
}

Why not let Sale tell the window directly? Because the Model–View Separation principle says domain objects must not know UI classes. Here Sale knows only PropertyListener, a UI-independent interface, and the list may even be empty. So the UI can be replaced without touching the domain, which is PV against a changing UI. Notice also that publishPropertyEvent iterates over a copy of the list; you will see why in the pitfalls below.

Observer is not only for UIs, and Larman gives other examples. GUI widget events work this way, with a JButton publishing action events. An AlarmClock publishes onAlarmEvent(source, time), and one clock can have many subscribers of different classes (AlarmWindow, Beeper, ReliabilityWatchDog), each reacting differently. In Java and .NET, the event is usually its own class (for example PropertyEvent with source, name, old value and new value), passed as the parameter.

Tony's Pizza: a complete Observer design exam-style

The week 9 case study is the course's fullest Observer design. It uses two interfaces: SubjectBase, with addObserver(o: ObserverBase) and notifyObservers(eventType: String, subject: SubjectBase), which holds 0..* observers; and ObserverBase, with update(eventType: String, subject: SubjectBase). The observers are:

• Restaurant, which observes its orders;
• Staff, who observe their restaurant (for in-app notifications) and the delivery assigned to them;
• Transaction, which places a pending charge when the order is submitted, and the real charge when delivery or pickup completes;
• Customer, who gets emails when an order is accepted, cancelled or ready for pickup;
• OrderLog, a Singleton, which timestamps every transition, including creation.

Three design points are worth taking from it.

• Restaurant is both observer and subject. It is notified of an order, then notifies its own staff. The restaurant manages its staff list itself because staff change and go on and off shift.
• Observers filter. "The onus is on the observer" to check the event type and subject, and to ignore what doesn't concern it. A Customer, for example, ignores "complaint received".
• Pass the subject in update instead of having the observer store one subject. One Restaurant observes many Orders, so it must be told which one changed.

Workshop 9's Monopoly Express logging engine (writing DiceValues_{player}.txt) is the same idea, with a logger subscribing to dice-placement events.

Push versus pull

There are two ways for an observer to get the data it needs. In the push model, the notification carries the data, as in Larman's onPropertyEvent(source, name, value) or an event object. In the pull model, the notification carries the subject, and the observer asks it for what it needs, as in the course's update(subject). Push gives the observer less coupling to the subject, but can send data it doesn't need. Pull is flexible, but couples the observer to the subject's interface.

Why it works: the GRASP behind it

Observer is based on Polymorphism: each listener answers update its own way. It gives Protected Variations, because the publisher is protected from knowing the specific class and the number of objects it notifies. And its Indirection through an interface gives Low Coupling, which is what makes Model–View Separation possible.

Pitfalls exam

• Memory leaks (lapsed listeners). The publisher holds strong references, so observers that are never unsubscribed stay alive. Unsubscribe on dispose, or use weak references.
• Update order is not guaranteed, so observers must not depend on each other's order.
• Cascades and cycles. An observer that changes the subject during update triggers more notifications, possibly infinitely.
• Hidden cost. A trivial setter can fan out to expensive updates.
• Concurrent modification. Subscribing or unsubscribing during notification breaks the iteration, so iterate over a copy, as the Sale code above does.
• Irrelevant events. Observers receive events they don't care about and have to filter them. Separate listener interfaces per event type help.
• Implicit control flow makes debugging harder: you cannot see from the publisher's code who will run.
• Java's original java.util.Observable/Observer is legacy. Larman notes that it was replaced by the Delegation Event Model in JDK 1.1, and it is deprecated in modern Java.

Template Method

Sometimes several classes follow the same procedure and differ only in one or two of its steps. Copying the procedure into each class duplicates code and lets the copies drift apart. Template Method writes the procedure once, in a superclass, and leaves blanks that subclasses fill in.

The lecture example: Starbuzz coffee and tea

The coffee and tea recipes share "boil water" and "pour in cup". They differ in brewing, where coffee uses brewCoffeeGrinds and tea uses steepTeaBag, and in condiments: sugar and milk for coffee, lemon for tea.

public abstract class CaffeineBeverage {
    public final void prepareRecipe() {          // template method: fixed skeleton, final
        boilWater(); brew(); pourInCup(); addCondiments();
    }
    protected void boilWater() { System.out.println("Boiling water"); }   // invariant steps
    protected void pourInCup() { System.out.println("Pouring into cup"); }
    protected abstract void brew();              // hooks / primitive operations
    protected abstract void addCondiments();
}
public class Tea extends CaffeineBeverage {
    protected void brew()          { System.out.println("Steeping the tea"); }
    protected void addCondiments() { System.out.println("Adding lemon"); }
}

Larman's vocabulary (chapter 37) names the parts. The template method is public, often final (UML {leaf}), and holds the unvarying algorithm. It calls hook methods, which are protected, either abstract or with a default implementation, and overridden in subclasses to supply the varying part. In the colour code, the abstract class is the abstraction, the template method inside it is the skeleton, and the subclasses are concrete.

This reversal of the usual direction, where the superclass calls the subclass's methods, is the Hollywood Principle: "Don't call us, we'll call you". It is the heart of (white-box) framework design: the framework owns the algorithm, and you plug your code into its hooks.

Larman's example: a persistence framework

In Larman's persistence framework, AbstractPersistenceMapper.get(oid) checks a cache; if the object isn't there, it calls the hook getObjectFromStorage(oid) and then caches the result. ProductDescriptionRDBMapper overrides the hook. The pattern is then applied again one level down: AbstractRDBMapper.getObjectFromStorage is a hook with respect to get, but a template with respect to getObjectFromRecord(oid, dbRec).

Two smaller examples show how common the shape is. A GUI update() { clearBackground(); repaint(); } is a template method whose hook is repaint(). And the Builder's makeJuice() from Part VI is also a template method.

GRASP and pitfalls

Template Method uses Polymorphism (through the hooks) and gives PV, because the invariant skeleton is protected and the extension points are explicit. It also supports High Cohesion, and reuse without duplicated code. Its weaknesses all come from inheritance:

• The variation is bound at compile time: there is one variation per subclass, and no swapping at run time (contrast Strategy).
• It suffers from the fragile base class problem, because changes to the skeleton ripple into every subclass.
• Make the template method final so that subclasses can't change the skeleton.
• Too many hooks become hard to understand.

Other GoF Patterns in the Textbook (Brief)

Three more patterns appear in Larman (chapters 36–37) but are not lecture topics. You won't be asked to design them, but they turn up as MCQ distractors, or as the textbook answer to a scenario, so you need to recognise each one from its problem and its shape.

Proxy (structural)

Larman (36.4) states the problem as "Direct access to a real subject object is not desired or possible." His solution reads: "Add a level of indirection with a surrogate proxy object that implements the same interface as the subject object, and is responsible for controlling or enhancing access to it." In the structure, the Client uses an «interface» ISubject, which is realised by both RealSubject and Proxy. The Proxy holds realSubject: ISubject, and its foo() does some pre-processing, calls realSubject.foo(), then does some post-processing.

There are several variants, named by what the extra step is for:

• a remote proxy is an RMI/CORBA client stub;
• a redirection proxy, also called a failover proxy, is the one drawn above: AccountingRedirectionProxy implements IAccountingAdapter and holds externalAccounting (for example SAPAccountingAdapter) and localAccounting (LocalAccounting); its postSale tries the external service and, if that fails, calls localAccounting.postSale(sale), which stores the sale to forward later;
• a virtual proxy does lazy materialisation: ManufacturerProxy holds an OID and materialises the real Manufacturer through PersistenceFacade on first use;
• a protection proxy (GoF) provides access control.

Remote-first versus local-first. Product lookups are local-first: LocalProducts implements IProductsAdapter, checks a persistent cache, and forwards misses to the remote adapter. ServicesFactory always returns this local service, so this part needs only Adapter and Factory. Accounting, by contrast, is remote-first, which is why it uses the redirection proxy. Larman also notes that one design can be several patterns at once: JavaPOS device classes are both Adapters and Proxies.

State (behavioural)

Larman (37.16) states the problem as "An object's behavior is dependent on its state, and its methods contain case logic reflecting conditional state-dependent actions. Is there an alternative to conditional logic?" The solution reads: "Create state classes for each state, implementing a common interface. Delegate state-dependent operations from the context object to its current state object. Ensure the context object always points to a state object reflecting its current state."

In Larman's example, PersistentObject.commit(), rollback(), save() and delete() delegate to PObjectState, whose states are New, OldClean, OldDirty, OldDelete and Deleted. State is one way to implement a state machine in code (see Part V). It looks just like Strategy on a class diagram; 7.7 explains how to tell them apart.

Command (behavioural)

The problem (Larman 37.17) is "How to handle requests or tasks that need functions such as sorting (prioritizing), queueing, delaying, logging, or undoing?" The answer is "Make each task a class that implements a common interface" (ICommand.execute(), undo()). The examples are DBInsertCommand, DBUpdateCommand and DBDeleteCommand in a Transaction, which sorts the commands (inserts, then updates, then deletes) before executing them; GUI cut and paste with an undo history stack; and a server-side CommandProcessor. A macro command is a Composite of commands.

Telling Confusable Patterns Apart exam

Many patterns share the same basic trick, an interface plus polymorphism, so their class diagrams look alike. MCQ distractors are chosen precisely from these look-alikes. The way through is to ask a few sharp questions about each group: what interface does the wrapper offer, what varies and who chooses it, how many children are there. Each group below gets a side-by-side picture and the guide's comparison table.

Wrappers: Adapter vs Façade vs Decorator vs Proxy

All four of these patterns wrap other objects, which is why they get confused. The rows that separate them best are the interface the wrapper offers compared with the wrapped object's, and the typical cue.

The lecture summary, following GoF, puts it this way: "Adapter provides a different interface to its subject. Decorator provides an enhanced interface." GoF adds that a proxy provides the same interface as its subject. Larman adds that a resource adapter wrapping an external system is also a kind of façade; it is called an adapter when the point is adapting varying interfaces.

Algorithm variation: Strategy vs State vs Template Method

All three patterns let behaviour vary. They differ in the mechanism, in what varies, and in who chooses the variant.

The lecture summary puts the key contrast in one line: "Template Method pattern uses Inheritance. Strategy pattern uses Delegation." The template method calls subclass methods, which is the Hollywood Principle, whereas "Calling a Strategy does not necessarily involve a structured process as in Template Method." The summary also quotes GoF: "Decorator lets you change the skin of an object. Strategy lets you change the guts."

Composite vs Decorator

Both patterns use recursive composition through a common Component type. They differ in how many children there are, in their purpose, and in what the operation does.

The lecture says the two intents are "distinct but complementary" and the patterns are "often used in concert". In S2 Q7, for example, Soloist (one ISound inside, embellishing it) is shaped like a decorator, while Duet (two children) is a composite (7.10).

Creational: Factory vs Builder vs Singleton (vs Abstract Factory)

The creational patterns are easiest to tell apart by the question each one answers, and by what it hands back.

Two more pairs that show up in MCQs

Strategy versus Adapter. Both rest on polymorphism behind one interface, and both give PV. But Strategy offers interchangeable algorithms that we write ourselves, while Adapter converts existing incompatible interfaces that we can't change, so the two are not interchangeable terms. A lecture poll tested this; try it below.

Strategy versus GRASP Polymorphism. Polymorphism, meaning subclasses of the domain class itself (like Payment.authorize(), "Do It Myself"), fits when the variation is fixed by the object's type. Strategy fits when there is a separate algorithm or policy object that a context delegates to and can swap at run time, such as a pricing rule or a tax calculation.

Pattern Recogniser exam

Q1 of the exam is ten multiple-choice questions, each a short scenario with GRASP and GoF patterns as options. You have about a minute each, so you need a fast way from the wording of a stem to a pattern. This section gives you that in three forms: a decision chart, the guide's full cue table with the distractor to watch for, and a set of practice scenarios.

Cue → pattern

Each row pairs a scenario cue with the pattern it points to. The last column names the distractor it is most easily confused with, and sometimes why that distractor is wrong.

Which pattern is this? Twelve practice scenarios

Cover the answer, decide in under a minute, then open it. These are new scenarios written to exercise each row of the table, not past-exam items.

Past Exams: "Describe This Class" exam

One 2021 question per paper (S1 Q8 and S2 Q3, 5 marks) showed some Java and asked you to describe it. The three bullets of the question are what get marked: name the pattern and explain its problem and solution, give an application, and write usage code. Answers that only name the pattern lose most of the marks. Below are the guide's full model answers and, for each, the much shorter official answer, so you can see what the minimum is.

S1 Q8: a Singleton Counter

public class Counter {
    private static final int RANGE = 1000;
    private int counter = 0;
    private static final Counter instance = new Counter();
    private Counter() { }
    public static Counter getInstance() { return instance; }
    public int getNext() { return counter++; }
    public void jumpToNextRange() { counter = ((counter / RANGE) + 1) * RANGE; }
}

Counter c = Counter.getInstance();
int a = c.getNext();                          // 0
int b = Counter.getInstance().getNext();      // 1: same instance, seen from anywhere
c.jumpToNextRange();                          // counter becomes 1000
int d = c.getNext();                          // 1000
System.out.println(c == Counter.getInstance());   // true
// Counter x = new Counter();                 // compile error: constructor is private

S2 Q3: Strategy for tax

The given code is ITaxAmount.getTax(double salary) with three implementations:

• PercentTaxAmount has percent = 0.21 and returns percent * salary;
• FlatTaxAmount returns 4800 if salary > 50 000, and 0 otherwise;
• BracketTaxAmount applies progressive brackets: 0 up to $20 000, then 21% of the excess over $20 000, then $12 402 + 31% of the excess over $100 000, and finally $51 667 + 45% of the excess over $180 000.

public class Employee {                                   // Context
    private final String name;
    private final double salary;
    private ITaxAmount taxPolicy;                         // typed to the Strategy interface
    public Employee(String name, double salary, ITaxAmount taxPolicy) {
        this.name = name; this.salary = salary; this.taxPolicy = taxPolicy;
    }
    public void setTaxPolicy(ITaxAmount p) { taxPolicy = p; }   // swap at run time
    public double getTax()    { return taxPolicy.getTax(salary); }
    public double getNetPay() { return salary - getTax(); }
}

ITaxAmount percent = new PercentTaxAmount();
ITaxAmount bracket = new BracketTaxAmount();
Employee e = new Employee("Ana", 120000, percent);
System.out.println(e.getTax());     // 25200.0  (0.21 * 120000)
e.setTaxPolicy(bracket);
System.out.println(e.getTax());     // 18602.0  (12402 + 0.31 * 20000)
e.setTaxPolicy(new FlatTaxAmount());
System.out.println(e.getTax());     // 4800.0

ITaxAmount tax1 = new PercentTaxAmount();
tax1.getTax(60000);  // 12600.00

ITaxAmount tax2 = new FlatTaxAmount();
tax2.getTax(70000);  // 4800.00

Past Exams: "List the GoF Patterns" (Q7.2) exam

Q7 in both 2021 papers gave about a page of Java, asked for a DCD (Q7.1) and a sequence diagram (Q7.3), and in between asked you to list the GoF patterns in the code (Q7.2, 5 marks). The DCDs and sequence diagrams are worked in Part III; here we do Q7.2. The rule is simple: name each pattern, then map every class to its role. Both papers contain the same two patterns, Composite and Strategy, and in both Strategy appears twice.

S1: the calculator

The classes are IExpr, BinaryExpr, UnaryExpr, Constant, IBinaryOp with Plus and Times, and IUnaryOp with UMinus. BinaryExpr.eval() is op.apply(left.eval(), right.eval()); UnaryExpr.eval() is op.apply(expr.eval()); Constant.eval() returns its value.

S2: the Musical Director's lineup

The classes are ISound, Instrument, Duet, Soloist, IDuetMusic with Jazz and Rock, and ISoloistMusic with Blues. Duet.play() returns music.playMusic(melodyInstrument, backingInstrument); Soloist.play() returns music.playMusic(instrument); Instrument.play() returns its type.

Past Exams: Composite Design Class Diagrams (Q9) exam

Q9 in both 2021 papers described a nested structure in words and asked for a design class diagram that answers a question about it. Both were "a clear application of the GoF Composition pattern", in the official answer's words. The work is mostly mechanical once you know the steps, and those steps are also what the markers check.

1. Find the operation(s) that must work uniformly on the whole and on its parts, and put them in the Component: an abstract class or interface, with an italic or «interface» name.
2. Make each atomic kind a Leaf subclass, and each grouping kind a Composite subclass.
3. Draw the recursive association from the Composite back to the Component, with a diamond on the composite end, role names and multiplicities.
4. Put the attributes in the right class, and put child management (add) only in the Composite, which is the safe form.
5. Label the roles («Component», «Leaf», «Composite» notes) and state "Composite pattern".
6. Add one-line method notes that show the recursion (for example, "sum of children's countBlack()").

S1: the quadtree image ("how many black pixels?")

Each square region is either uniformly black, white or outside the image, or it is divided into exactly four sub-quadrants: NE, SE, SW and NW. In the guide's design, Black.countBlack() returns size * size, where size is the side length in pixels, a power of two. White and Outside return 0, and Divided.countBlack() returns ne.countBlack() + se.countBlack() + sw.countBlack() + nw.countBlack().

Some design points behind it:

• The four role-named associations, each with multiplicity 1, capture "exactly four quadrants labelled NE, SE, SW, NW". The alternative is one association with multiplicity 4. On its own that loses the labels, but the official answer (below) keeps them by typing the field as a map keyed by an enumeration of the four sectors, so a single 4 association is fine when paired with that map.
• Composition (the filled diamond) is appropriate, because a sub-quadrant belongs to exactly one parent, although a hollow diamond, as in the generic slide, is also accepted.
• A design alternative is to pass the size as a parameter, countBlack(side: int); the leaves then have no state and could be shared (Flyweight).
• QuadTreeImage is optional: it holds the root and the real image dimensions. Construction is excluded, as the question says.

The official Component is an interface, IBWImage, with two operations, getSize() and numBlack(). There is only one leaf class, Pixel; the guide's three leaf subclasses are a defensible alternative, since the three kinds differ only in what the two operations return. Everything the checklist asks for is there: the pattern named, the recursive association typed to the Component, the exact multiplicity, and the operations explained. The official answer adds getSize(), which the question does not strictly need, so treat it as optional.

S2: a fleet of vessels

The queries are "how many sailors in the fleet?" and "make the whole fleet sail". Vessels (Ship, Yacht, Ferry) each have a number of sailors and a length, and can sail. Ships have a name, and ferries carry a number of passengers. A fleet has at least two vessels, an admiral's ship and a scouting yacht, plus any number of others.

Should Fleet be a subtype of Vessel? Composite needs Fleet to share the operations the client uses uniformly: getSailorCount() and sail(). But a fleet is not a kind of vessel. It has no single length and no crew of its own, and inheriting Vessel's attributes would break the "is-a" rule (Liskov substitution). The cleaner design puts the operations in an interface that both the abstract Vessel and Fleet realise.

Here NavalUnit is the Component, Ship, Yacht and Ferry (through the abstract Vessel) are the Leaves, and Fleet is the Composite. Fleets can be nested if others is typed as NavalUnit; type it as Vessel if nested fleets should be forbidden. Because "vessels can be added to the fleet", there is an add(), and it lives only in Fleet, which is the safe form.

Common Mistakes Markers Penalise exam

Most lost marks on pattern questions come from a short list of repeated errors, some in the drawing and some in the written answer. Read the list once now, and again the day before the exam; the pictures show the three most common diagram errors next to their fixes.

The full list

1. Wrong arrowheads. Realisation (a dashed line with a hollow triangle), generalisation (a solid line with a hollow triangle) and association (an open arrow) must be kept distinct. Workshop 11 warns that markers "will not be guessing" what an arrow means.
2. Associations to concrete classes when the context should hold an interface. Sale should point to ISalePricingStrategy, not to PercentDiscount….
3. Composite errors: a missing recursive link, a link pointing at Leaf, a missing multiplicity (0..*, or exactly 4 for the quadtree), the Composite not realising or extending the Component, and child operations placed on the leaves.
4. Decorator errors: a decorator that doesn't implement the component interface or doesn't hold the wrapped component (multiplicity 1), and describing plain subclassing as "Decorator".
5. Singleton errors: a public constructor, a non-static instance or getInstance, or a missing private constructor, and forgetting thread safety when asked about lazy initialisation.
6. Observer errors: a publisher that depends on concrete observer classes, or the lack of any register/subscribe operation.
7. Strategy errors: having no context object, or choosing the strategy with a switch inside the context, which defeats the purpose.
8. "Describe this class" answers that only name the pattern. You must cover problem and solution, an application and usage code, which are the three bullets in the question. The code should compile and use the abstract type.
9. "List the patterns" answers that don't map classes to roles. Each pattern use needs its elements named.
10. Pattern-itis. Larman ch. 36 and the workshops warn that patterns force-fitted to trivial problems over-complicate the design, so justify every pattern by the variation or problem it addresses.