Design Patterns I: Façade to Singleton

Foundations: Patterns, GoF and the Exam exam

Experienced designers keep meeting the same problems: "these three services do the same job through different APIs", "this object needs optional extras", "there must be only one of these". Rather than re-invent a solution each time, they reuse one that is known to work and give it a name. This section explains what such a named solution is, where the famous list of 23 comes from, how patterns connect to the GRASP principles of Part IV, and how to write about a pattern so that it earns marks.

How to read the diagrams on this page

Every pattern is a cast of roles: someone who calls, an abstraction that hides the variety, the new class the pattern introduces, and the existing classes doing the real work. So that you can spot the same role across different patterns, every diagram on this page (and in Part VII) colours the roles the same way, and the prose uses matching coloured names such as Client or Adapter.

What a design pattern is

The name matters as much as the solution. Because each pattern has a name, designers gain a shared vocabulary and can say a lot in a few words. Larman's example sentence is "let's use Adapters generated from a Singleton Factory". To anyone who knows the patterns, those seven words describe three cooperating designs, which you will meet in 6.5, 6.6 and 6.8, and see working together at the end of this Part.

The Gang of Four and their 23 patterns

GoF stands for the "Gang of Four": Gamma, Helm, Johnson and Vlissides, who wrote Design Patterns: Elements of Reusable Object-Oriented Software (1995). The book describes 23 patterns, originally illustrated in C++ and Smalltalk, and sorts them into three categories according to what they are concerned with. The exam sometimes asks for a pattern's category, so learn which column each taught pattern sits in.

A quick way to remember the categories: creational patterns answer "how does this object get made?", structural patterns answer "how are these objects wired together?", and behavioural patterns answer "who does what, and how do they talk?". In this Part, Façade, Decorator and Adapter are structural, while Builder, the Factory family and Singleton are creational.

GRASP is the "alphabet" behind GoF exam

The GRASP principles of Part IV are general advice about assigning responsibilities. Larman argues that most design patterns are just specialisations of a few GRASP principles. That is useful in the exam: if you can name the GRASP principles a GoF pattern relies on, you can justify the pattern in any written answer. Larman makes four general claims.

1. Every GoF pattern is a Pure Fabrication. In his words, "All GoF design patterns … are Pure Fabrications": each one invents a class that is not a domain concept (no shop has a "ServicesFactory").
2. Adapter, Façade and Observer specialise Indirection: they put an intermediate object between two others so that they are not directly coupled.
3. Adapter, Command, Composite, Proxy, State and Strategy rely on Polymorphism: several classes share one interface, and the caller doesn't care which it gets.
4. Almost every pattern exists to provide Protected Variations (PV), mainly through Low Coupling: it builds a stable interface around a point that is likely to change.

Pattern by pattern, the GRASP principles each one applies are as follows. Where Larman gives wording, it is his. You don't need to memorise every cell; aim to be able to give two principles for any pattern.

* Larman does not cover Decorator or Builder, so those two rows are reasoned from the course slides and GoF.

How to write about a pattern in the exam exam

Questions such as "describe this Java class" or "which pattern would you use, and why?" reward a fixed shape of answer. Follow the same five steps every time, and you will not forget a part that carries marks.

1. Name the pattern and its category ("Adapter, a structural GoF pattern").
2. State the problem in the scenario's terms, not in textbook terms: "several tax calculators with different APIs that we cannot change".
3. Give the solution and roles by mapping every pattern role to a concrete class in the question: "ITaxAmount = Strategy interface; PercentTaxAmount = ConcreteStrategy; Employee = Context".
4. Explain why it helps by naming GRASP principles (PV, Low Coupling and so on), plus one trade-off.
5. If asked, give a usage code fragment that compiles and shows the client using only the abstract type.

UML notation used with patterns

Pattern diagrams lean on a handful of UML conventions that are easy to get subtly wrong, and markers notice. The numbered badges are explained below the figure.

1. Interfaces and realisation. An interface carries the «interface» keyword. A class that implements it is joined by a dashed line with a hollow triangle (in Java, implements).
2. Abstract classes and subclassing. An abstract class or method has an italic name, or is marked {abstract}. Subclassing (extends) is a solid line with a hollow triangle.
3. Singleton marker. A singleton class may show a "1" in the top-right corner of its name compartment.
4. Static members are underlined, such as a singleton's instance field and getInstance() method.
5. Point at the interface. Associations and attribute types should target the interface, not a concrete class, so that any implementation can be plugged in.
6. A lifeline marked "1" means the object was reached through Singleton, so the getInstance() call is implicit and not drawn.

One more convention is a matter of style: Larman's guideline is to put the pattern name in the class name (TaxMasterAdapter, ServicesFactory, CompositeBestForCustomerPricingStrategy), because it tells readers immediately which pattern is in play.

Façade structural exam

Some parts of a system are big and messy: dozens of interdependent classes, a third-party library, or a part whose design hasn't even been decided yet. If every other class talks to it directly, they all become coupled to its insides, and any change ripples outwards. Façade solves this by putting one front door on the subsystem.

Larman phrases the problem as a question: a common, unified interface to a disparate set of implementations or interfaces (such as within a subsystem) is required; there may be undesirable coupling to many things in the subsystem, or its implementation may change. What to do? His solution is to define a single point of contact to the subsystem: a façade object that wraps it, presents one unified interface, and is responsible for collaborating with the subsystem's components. Everything else in the subsystem is private.

The problem, and the fix

The lecture's ATM example shows the problem plainly. To withdraw cash, the ATM has to check the account number, check the security code, check the funds, update the account and record a transaction, each in a different class.

Structure and participants

There are three participants:

• the Façade, whose interface is tailored to what external clients need. It may deliberately not expose everything the subsystem can do;
• the subsystem classes, which do the real work and don't know the façade exists;
• the clients, which talk only to the façade.

Notice there is no interface in the generic structure. Unlike Adapter or Decorator, Façade doesn't rely on polymorphism; it is pure Indirection. That is a useful clue when you are deciding between patterns.

Course example 1: pluggable business rules in the NextGen POS

This is Larman's main example (26.9) and the lecture's. The customers want rules that can invalidate an action. For example:

• a gift-card sale may contain only one item and must give no cash change;
• a charity sale may only be rung up by a manager as cashier, and no item may cost over $250.

The architect wants these rules to have low impact on existing components, and is not yet sure how the rules will be implemented: as Strategy objects, with a free rule interpreter, or with a commercial one. A façade hides that choice completely. Behind it, the rule engine could be hundreds of classes, or not even object-oriented, and the domain objects would never know.

In code, the façade is public and the rule interface is package-private. The domain class Sale gets a one-line hook: before adding a line item, it asks the façade whether the item is invalid.

// package posruleengine
public class POSRuleEngineFacade {
    private static POSRuleEngineFacade instance;              // façades are usually Singletons
    private final List<IRule> rules = new ArrayList<>();      // hidden subsystem parts

    private POSRuleEngineFacade() { /* load rules: Strategy objects, a rule interpreter, ... */ }

    public static synchronized POSRuleEngineFacade getInstance() {
        if (instance == null) instance = new POSRuleEngineFacade();
        return instance;
    }
    public boolean isInvalid(SalesLineItem sli, Sale sale) {
        for (IRule r : rules) if (r.invalidates(sli, sale)) return true;
        return false;
    }
}
interface IRule { boolean invalidates(SalesLineItem sli, Sale sale); }   // package-private

// client: the one-line hook into the domain (Larman / lecture code)
public class Sale {
    public void makeLineItem(ProductDescription desc, int quantity) {
        SalesLineItem sli = new SalesLineItem(desc, quantity);
        if (POSRuleEngineFacade.getInstance().isInvalid(sli, this)) return;   // call to the Façade
        lineItems.add(sli);
    }
}

Step through the same code as a sequence diagram to see the collaboration at run time.

Course example 2: the ATM

The ATM example from the tabs above is the lecture's. BankAccountFacade(accountNumber, securityCode) offers withdrawCash(amount) and depositCash(amount), and internally coordinates the five classes AccountNumberCheck, SecurityCodeCheck, FundsCheck, Account and Transaction. Without the façade, the ATM would be coupled to all five.

Course example 3: Monopoly LuckCards (workshop 7)

When a player lands on Go To Jail, they now draw from a deck of 5 cards: 1 × JailExemptionCard (stay where you are), 2 × GoToJailCard (move to Jail) and 2 × PayJailFeeCard (pay $500, or go to Jail if you can't afford it). The requirement was that GoToJailSquare should change by roughly one statement.

The "one statement" in GoToJailSquare's landedOn becomes a call such as CardDeckFacade.getInstance().drawJailCard(), followed by letting the drawn card apply its effect. Everything about the deck, the random draw and the card mix stays behind the façade.

Why it works: GRASP

Façade versus Controller

The workshop 7 slides warn against confusing Façade with the GRASP Controller of Part IV, partly because Larman himself uses the phrase "façade controller".

Larman's "façade controller" (for example a Register that represents the whole system) is a Controller that happens to act as a front for the domain layer. Don't let the name trick you into calling it a GoF Façade.

Consequences and pitfalls

Decorator structural exam

A noodle shop sells a base soup, and customers add any number of extras: prawns, egg, tofu, chilli, even two eggs. Every extra changes the same few outputs: the price, the ingredient list, the allergens. How do you model "a base thing plus any combination of add-ons, chosen while the program runs" without writing a class for every combination? That is Decorator's problem.

The slides pose the problem as: how do we dynamically add behaviour or state to individual objects at run time, without changing the interface presented to the client? Inheritance doesn't fit, for two reasons. It is static, fixed when the code is compiled, and it applies to the whole class, whereas we want to change one instance, in any combination.

The problem, and the fix

The slides' solution: encapsulate the original concrete object inside an abstract wrapper interface, and let the decorators that hold the extra behaviours also inherit from that interface. The interface then uses recursive composition to allow an unlimited number of decorator "layers" around each core object.

Participants

• Component: an interface or abstract class. As workshop 7 puts it, "we can use either an interface OR an abstract class … at the top".
• ConcreteComponent: the core object being decorated (the plain soup).
• Decorator: abstract. It implements Component and also holds one Component, the wrapped object. By default it simply forwards every call to it.
• ConcreteDecorator: overrides operations, calling the wrapped object and adding its own behaviour (addBehaviour()) either before or after that call.

Watching it work: a laksa, layer by layer

The past-exam noodle soup scenario appeared in both semesters' MCQs (S1 Q1.2 and S2 Q1.4). Here is one order being built, then priced.

The code

public interface Soup {                                   // Component
    double getPrice();
    List<String> getIngredients();
    Set<String> getAllergens();
    int getReheatSeconds();
}

public class NoodleSoup implements Soup {                 // ConcreteComponent
    private final double basePrice; private final String soupType, noodleType;
    public NoodleSoup(double basePrice, String soupType, String noodleType) {
        this.basePrice = basePrice; this.soupType = soupType; this.noodleType = noodleType;
    }
    public double getPrice()             { return basePrice; }
    public List<String> getIngredients() { return new ArrayList<>(List.of(soupType, noodleType)); }
    public Set<String> getAllergens()    { return new HashSet<>(Set.of("gluten")); }
    public int getReheatSeconds()        { return 120; }
}

public abstract class SoupDecorator implements Soup {     // Decorator
    protected final Soup inner;                           // the wrapped component
    protected SoupDecorator(Soup inner) { this.inner = inner; }
    public double getPrice()             { return inner.getPrice(); }        // default: forward
    public List<String> getIngredients() { return inner.getIngredients(); }
    public Set<String> getAllergens()    { return inner.getAllergens(); }
    public int getReheatSeconds()        { return inner.getReheatSeconds(); }
}

public class Prawns extends SoupDecorator {               // ConcreteDecorator
    public Prawns(Soup inner) { super(inner); }
    @Override public double getPrice() { return inner.getPrice() + 4.00; }
    @Override public List<String> getIngredients() { List<String> l = inner.getIngredients(); l.add("prawns"); return l; }
    @Override public Set<String> getAllergens() { Set<String> s = inner.getAllergens(); s.add("crustacean"); return s; }
    @Override public int getReheatSeconds() { return inner.getReheatSeconds() + 30; }
}
// Egg, Tofu, Chilli ... are written the same way.

// Client: any combination, chosen at run time, through the same interface
Soup order = new Prawns(new Egg(new Egg(new NoodleSoup(12.0, "laksa", "rice"))));
double price = order.getPrice();          // 12.0 + 1.5 + 1.5 + 4.0
Set<String> allergens = order.getAllergens();

Three things to notice. Each decorator's constructor takes a Soup, which is what lets layers nest. The abstract decorator's default forwarding means a concrete decorator only overrides what it changes. And the client line never mentions a decorator type on the left-hand side: it is just a Soup.

Course example 1: shapes (lecture)

The component is Shape with draw(), and Rectangle implements it. The abstract ShapeDecorator implements Shape holds protected Shape decoratedShape, and its draw() forwards. RedShapeDecorator.draw() calls decoratedShape.draw() and then setRedBorder(decoratedShape). The sequence diagram below shows a rectangle with a blue fill, wrapped by a red border.

Course example 2: Monopoly houses and gardens (workshop 7, part 2)

Here the abstract Square with landedOn(Player) is the Component, and RegularSquare is the ConcreteComponent. The abstract SquareDecorator extends Square, holds wrapped: Square and owner: Player, and adds collectIncome(). House (+$20 to the owner) and Garden (+$5 × visits, with INCOME_PER_VISIT and n_visits) are the concrete decorators.

Why it works: GRASP

Consequences and pitfalls

Here is the ordering problem with a $10 pizza, a "10% discount" decorator and a "+$2 topping" decorator. The same two decorators, stacked in different orders, give different prices.

Builder creational

Some objects are hard to make. They have many parts or optional fields, they must be assembled in the right order, and building them takes domain knowledge the code that uses them shouldn't need. If that construction code lives in the client, the client becomes cluttered and has to change whenever the product does. Builder moves the whole job of construction into its own object.

The slides pose the problem as two questions. How can a class (the same construction process) create different representations of a complex object? And how can a class that includes creating a complex object be simplified? Their solution: encapsulate creating and assembling the parts of a complex object in a separate Builder object. A class delegates object creation to a Builder instead of creating the objects directly.

The problem, and the fix

Pizza p = new Pizza(30, true, false, true, false, false, true);   // which flag is ham?

Participants

• Builder: the abstract interface for building the parts.
• ConcreteBuilder: implements the steps, keeps the product being built, and returns it with getResult().
• Director: calls the steps in a fixed order.
• Product: what comes out.

Course example 1: Monopoly houses (workshop 7, part 3)

In this workshop, houses are built with the provided regularHouseBuilder.jar API, and the house type depends on the player's net worth: $50–100 builds a single-pen house, $101–300 a saddlebag, and $301 and above a dogtrot.

public abstract class HouseBuilder {                   // Builder
    protected House house = new House();
    public abstract void setFoundation();
    public abstract void setRooms();
    public abstract void setRoof();
    public abstract void setGeneratedAmount();
    public House buildHouse() { return house; }         // GoF getResult()
}
public class SaddleBagHouse extends HouseBuilder {     // ConcreteBuilder: holds the domain knowledge
    public void setFoundation()      { /* saddlebag foundation */ }
    public void setRooms()           { house.setNumRooms(2); }
    public void setRoof()            { /* ... */ }
    public void setGeneratedAmount() { house.setAmountGenerated(/* computed rent per visitor */ 50.46f); }
}
public class HouseManager {                            // Director: fixes the construction order
    private final HouseBuilder builder;
    public HouseManager(double netWorth) {             // picks the representation
        builder = netWorth <= 100 ? new SinglePenHouse()
                : netWorth <= 300 ? new SaddleBagHouse() : new DogTrotHouse();
    }
    public House construct() {
        builder.setFoundation(); builder.setRooms(); builder.setRoof(); builder.setGeneratedAmount();
        return builder.buildHouse();
    }
}
// client (e.g. RegularSquare): knows nothing about how houses are built
float rent = new HouseManager(player.getNetWorth()).construct().getAmountGenerated();

In this code the Director chooses the builder itself from the net worth. The workshop's partial-solution sequence diagram does it slightly differently: the client creates SaddleBagHouse(netWorth) and passes it to HouseManager(builder), the manager calls the four steps, and the client then calls buildHouse(): House on the builder. Step through that version below.

Course example 2: the lecture's generic sequence

The lecture's generic version runs in three steps: (1) the client calls Director.getWidget("One"): Widget; (2) the Director creates ConcreteBuilderOne and calls buildWidget(): Widget; (3) the builder creates the Widget and calls its own buildPartA(), buildPartB() and buildPartC().

Course example 3: juice (lecture)

The sequence starts with BuilderClient → ShopKeeper.takeOrder(juiceType): Juice. ShopKeeper is the Director, and it aggregates the abstract builder JuiceMaker, which has setFruit(), setWater(), setSugar() and public final Juice makeJuice(). OrangeJuiceMaker and AppleJuiceMaker implement the steps. makeJuice() creates the juice, calls setJuiceType(), setWater(), setFruit() and setSugar(), and returns it. Because it is final, no subclass can change the recipe, which guarantees every juice is made the same way.

Why it works: GRASP

Consequences and pitfalls

You will also meet the fluent builder Java idiom, which solves the telescoping-constructor problem without a Director. It is a popular variant, not the GoF structure:

Pizza p = new Pizza.Builder(size).cheese().ham().build();

Adapter structural exam

Real systems talk to things they don't control: tax calculators, accounting packages, airline booking services, drones from different manufacturers. Several of them may do the same job through different APIs, and you can't change those APIs. Adapter lets your code treat them all the same way, through one interface that you define.

Larman's problem: how to resolve incompatible interfaces, or provide a stable interface to similar components with different interfaces? His solution: convert the original interface of a component into another interface, through an intermediate adapter object. Note that "interface" here means the set of operations, not necessarily a Java interface.

The problem, and the fix

Tony's Pizza (the week 7 case study) delivers by drone, and its drones come from three manufacturers, each with its own software package. The packages differ in their payload types, in whether a location is a latitude/longitude or a street address, and in whether pizzas and drinks have separate compartments.

The target interface IDroneAdapter has deliverOrder(order: Order) and setRestaurant(r: Restaurant). The whole Order is passed because it is the Information Expert on its items and delivery address. To convert addresses, each adapter uses a private helper convertAddress(String): DroneLocation that calls a maps service. It is private because its signature differs per manufacturer; separate location adapters would be the alternative.

Structure and participants

• Target: an interface that we define, such as ITaxCalculatorAdapter.
• Adapter: implements the Target and holds a reference to the adaptee, translating both the calls and the data.
• Adaptee: the existing external class or system.
• Client: depends only on the Target.

Course example 1: Disney characters (lecture)

The lecture's toy example makes the idea concrete. A game wants every character to move(), but the characters come from an external library where a sloth must be woken and pushed to climb, Iron Man flies, and a trooper is controlled by a command string.

public interface IDisneyAdapter { void move(); }        // Target (our interface)

public class SlothAdapter implements IDisneyAdapter {   // Adapter
    private final Sloth theSloth;                       // Adaptee from an external library
    public SlothAdapter(String name) { theSloth = new Sloth(name); }
    public void move() { theSloth.wake(); theSloth.pushToClimb(); }   // translate one call into their API
}
// Client: no knowledge of how each character moves (lecture code)
IDisneyAdapter sloth = new SlothAdapter("Flash");   sloth.move();
IDisneyAdapter ironMan = new IronManAdapter("Tony"); ironMan.move();

Notice that one call to move() may become several calls on the adaptee. Translation is not always one-to-one.

Course example 2: NextGen POS external services (Larman 26.1)

The POS must work with several tax calculators (TaxMaster, GoodAsGoldTaxPro), accounting systems (SAP, GreatNorthern), credit authorisation services and inventory services, each with a fixed API. Larman defines one target interface per kind of service, and one adapter class per external system.

A side note from Larman: while designing this, the class TaxLineItem appeared. It is a domain concept discovered during design, and can be added back to the Domain Model. Models evolve in both directions.

Course example 3: MiniExpedia (workshop 8)

MiniExpedia searches and books flights across Jetstar, Qantas and Virgin. The search target is ISearchAdapter.search(myFlights: ArrayList<IFlightAdapter>, numPassengers): ArrayList<IFlightAdapter>, implemented by JetstarSearchAdapter, QantasSearchAdapter and VirginSearchAdapter. Jetstar's search API has a stateful protocol: it must be called in exactly the right order, and calling it in the wrong state throws an exception. The adapter hides this sequence.

No adapter is needed for Passenger, because the IBookAdapter implementation creates the airline's own passenger objects itself. The client's search loop gets each adapter from a factory, which is where the next section begins:

searchAdapter = ServiceFactory.getInstance().getSearchAdapter(airlines[i]);
results.addAll(searchAdapter.search(myFlights, numPassengers));

Why it works: GRASP

Variants: object adapter and class adapter

Either way, an adapter may translate data in both directions: sending requests out, and turning replies back into our types (as JetstarFlightAdapter does). Exceptions should be translated to our level of abstraction too (Larman's "Convert Exceptions", ch. 36), so a SOAP fault doesn't leak into the domain layer.

Pitfalls, and the two questions Adapter raises

Using adapters raises two follow-on questions, and two more patterns answer them. Who creates the adapters, and how is the right class chosen? That is Factory (6.6). How does everyone reach that factory? That is Singleton (6.8).

Factory (Simple / Concrete Factory) creational, not GoF exam

Adapter left a loose end: somebody has to create the adapters, and somebody has to decide whether today's tax adapter is TaxMasterAdapter or GoodAsGoldTaxProAdapter. If a domain object does it, it gets tangled up in configuration and external connectivity. Factory gives that job to a dedicated object. Three designs share the word "factory"; this section covers the one the course uses most, and 6.7 covers the two GoF ones and compares all three.

Its problem: who should be responsible for creating objects when there are special considerations, such as complex creation logic, or a desire to separate the creation responsibilities for better cohesion? Its solution: create a Pure Fabrication object called a Factory that handles the creation.

The problem, and the fix

The motivation comes straight from Adapter. Who creates the adapters, and how do we choose TaxMasterAdapter over GoodAsGoldTaxProAdapter? If a domain object such as Register did it, that would go beyond pure application logic into external connectivity. That breaks separation of concerns (an application of High Cohesion) and lowers Register's cohesion.

What a factory buys you

Data-driven and lazy: ServicesFactory in code

Larman's ServicesFactory adds two refinements. The choice of class is data-driven: it reads the class name from a system property (taxcalculator.class.name=TaxMasterAdapter) and instantiates it reflectively, so switching adapter needs no source change, which is PV. And it uses lazy creation: an adapter is created only when first asked for, and then cached.

public class ServicesFactory {                                   // Factory + Singleton
    private static ServicesFactory instance;
    private ITaxCalculatorAdapter taxCalculatorAdapter;

    private ServicesFactory() {}
    public static synchronized ServicesFactory getInstance() {
        if (instance == null) instance = new ServicesFactory();
        return instance;
    }
    public ITaxCalculatorAdapter getTaxCalculatorAdapter() {
        if (taxCalculatorAdapter == null) {                      // lazy creation
            String className = System.getProperty("taxcalculator.class.name");  // data-driven: PV
            try {
                taxCalculatorAdapter = (ITaxCalculatorAdapter)
                    Class.forName(className).getDeclaredConstructor().newInstance();
            } catch (ReflectiveOperationException e) { throw new IllegalStateException(e); }
        }
        return taxCalculatorAdapter;
    }
}

The lecture's Disney version replaces reflection with a plain conditional:

// Disney version (lecture): a conditional instead of reflection
public IDisneyAdapter getDisneyAdapter(String character, String name) {
    if (character.equals("ironman")) return new IronManAdapter(name);
    if (character.equals("sloth"))   return new SlothAdapter(name);
    if (character.equals("trooper")) return new TrooperAdapter(name);
    return null;                     // the slides suggest an Enum instead of a String
}

Caching is a choice, not a rule. PricingStrategyFactory (Part VII) deliberately does not cache, because the pricing policy can change hourly, so it re-creates the strategy each time. And use a separate factory for each family of products, as with ServicesFactory and PricingStrategyFactory, because that keeps each factory cohesive.

The course's factories

All the shared ones are Singletons.

Why it works: GRASP

Factory Method and Abstract Factory creational, GoF

The two GoF patterns with "factory" in their name solve related but different problems. Factory Method lets a class leave one creation decision to its subclasses. Abstract Factory creates whole families of objects that must be used together. Knowing exactly how they differ from the Simple Factory above is the main exam value of this section.

Factory Method

In its structure, an abstract Creator declares createProduct(): Product, and may call it inside its own template-like operations. Each ConcreteCreator overrides it to return a ConcreteProduct. The workshop 8 slide describes it as "replace direct object construction calls with calls to a special factory method". Use it when you don't know the exact types in advance, to let users of a framework extend its internal components, or to save resources by reusing objects.

public abstract class Dialog {                       // Creator
    public void render() { Button ok = createButton(); ok.render(); }
    protected abstract Button createButton();        // the factory method
}
public class WebDialog extends Dialog {              // ConcreteCreator
    protected Button createButton() { return new HtmlButton(); }
}

Abstract Factory (Larman 36.7)

Larman's problem: how to create families of related classes that implement a common interface? His solution: define a factory interface (the abstract factory), and define a concrete factory class for each family of things to create. Optionally, define a true abstract class that implements the factory interface and provides common services to the concrete factories that extend it.

His example is the JavaPOS device drivers. A store's cash drawer, coin dispenser and so on must all come from the same manufacturer's driver set. IJavaPOSDevicesFactory declares getNewCashDrawer(): jpos.CashDrawer, getNewCoinDispenser(): jpos.CoinDispenser and so on, and IBMJavaPOSDevicesFactory and NCRJavaPOSDevicesFactory each return their own manufacturer's driver family.

There is also an abstract-class variant. The abstract JavaPOSDevicesFactory has a Singleton getInstance() that reads the system property jposfactory.classname and instantiates the matching subclass. Client code is then a single line, which gives PV over which family is used. java.awt.Toolkit works this way.

cashDrawer = JavaPOSDevicesFactory.getInstance().getNewCashDrawer();

Telling the three factories apart exam

The quickest way to tell them apart is the mechanism: one class decides, subclasses decide, or there is one concrete factory per family.

Singleton creational exam

Some things must exist exactly once: the one order log, the one configuration, the one factory that hands out adapters. Many objects scattered across the system need to reach that one object, and passing it along as a parameter through every method call would be tiresome. Singleton guarantees there is only one, and gives everyone a way to find it.

Larman's problem: exactly one instance of a class is allowed (it is a "singleton"), and objects need a global and single point of access. His solution: define a static method of the class that returns the singleton.

The problem, and the fix

Tony's Pizza (week 9) wants "a single log for all orders and deliveries". The class names on the left of these pictures are illustrative.

Mechanics

1. A private static field holds the sole instance.
2. A private constructor, so there is no new from outside the class.
3. A public static getInstance() that returns the instance.
4. Service methods stay instance methods; only the access point is static.

Lazy versus eager initialisation exam

There are two ways to decide when the one instance is created.

// Lazy (Larman's preferred form): created on first use
public class ServicesFactory {
    private static ServicesFactory instance;
    private ServicesFactory() {}
    public static synchronized ServicesFactory getInstance() {   // synchronized: the creation step is
        if (instance == null) instance = new ServicesFactory();  // a critical section when multithreaded
        return instance;
    }
}
// Eager: created when the class is loaded
public class ServicesFactory {
    private static final ServicesFactory instance = new ServicesFactory();
    private ServicesFactory() {}
    public static ServicesFactory getInstance() { return instance; }
}

Why does lazy initialisation need synchronized? Step through what can happen without it.

Beyond the textbook, common Java idioms are the initialisation-on-demand holder (lazy, thread-safe, no locking), the enum singleton (also safe against serialisation and reflection), and double-checked locking, which needs a volatile field. Whichever you use, remember that thread-safe creation does not make the singleton's state thread-safe: a mutable counter inside it still needs synchronized or an AtomicInteger.

Why not just make every method static?

A class with only static methods also has "one copy". Larman gives three reasons to prefer a real instance:

1. Polymorphism. Instance methods can be overridden in subclasses; static methods are not polymorphic. (This is what lets JavaPOSDevicesFactory.getInstance() return an IBM or NCR subclass.)
2. Remoting. Remote mechanisms such as Java RMI only remote-enable instance methods.
3. Flexibility. A class is not a singleton in every application, and designs often discover later that they need several instances (a "multi-ton"). Instance-side code keeps that option open.

Singleton in UML

In the class box, draw a "1" in the top-right corner and underline the static instance and getInstance() (see the notation figure in 6.1). In a sequence diagram, a lifeline box marked "1", such as 1 :ServicesFactory, means visibility came through Singleton, and the getInstance() message is then implicit and not drawn (Larman Fig. 26.7). In code this is:

aa = ServicesFactory.getInstance().getAccountingAdapter();

Course singletons

Putting Part VI together: Adapters from a Singleton Factory

Remember Larman's sentence from 6.1, "let's use Adapters generated from a Singleton Factory"? Here it is as a sequence diagram (Larman Fig. 26.8). Three patterns cooperate: the Singleton makes the factory reachable from anywhere, the Factory creates the right adapter, and the Adapter hides the external system.

Larman sums up the reasoning behind this design as a chain of principles and patterns: Controller, Creator, Protected Variations, Low Coupling, High Cohesion, Indirection, Polymorphism, Adapter, Factory and Singleton.

Pitfalls (be ready to discuss) exam

The past-exam "describe this Java class" question about a Singleton counter, with its official answer, is worked through in Part VII.