Last creational-patterns lecture: a revision of Abstract Factory and Factory Method, then Builder and Singleton. Both were on Final 252.

Revision of the two factory patterns.

Builder, with a code-generator example.

Singleton, with an event-manager example.

Abstract Factory revised: an AbstractFactory with one create method per product; ConcreteFactory1 and 2 each create one family (A1+B1, A2+B2). Creator classes on the left, product classes on the right; the client uses only the interfaces.

The same structure applied to the computer store: ComputerPartsFactory creates a Monitor, CPU and Keyboard; the Advanced and Standard factories each create their own matching set.

Factory Method revised: an abstract Creator with createProduct() and someOperation(); a ConcreteCreator overrides createProduct() to return a ConcreteProduct. One product, chosen by a subclass. Factories must obey the factory (creator) interface; products must obey the product interface.

Factory Method applied: ComputerStore’s createComputer(type) is overridden by StandardComputerStore and AdvancedComputerStore, which return StandardComputer and AdvancedComputer through the Computer interface.

The Builder’s intent: separate the construction of a complex object from its representation…

…so that the same construction process can create different representations. The steps (the algorithm) stay fixed; what each step produces varies with the builder.

Step 1: identify and design the product class (GeneratedProduct).

Step 2: identify the product’s creational process and algorithm, and design a class that executes it (CodeGenerator, the director).

Step 3: from steps 1–2, design the builder interface: abstract methods for every part that must be created for the whole product to exist; concrete builders implement them.

Step 4: design one class per representation of the product (CppMessageBuilder, JavaMessageBuilder…).

Intent: separate how a complex object is built (the steps) from what the result looks like (the representation).

When useful: same construction steps, different outputs, e.g. generating Java vs. C# code, or a small vs. large burger.

Roles: Director (orchestrates the steps in order, knows no details); Builder interface (declares the step methods buildPartA/B/C… and getProduct()); ConcreteBuilders (implement the steps for each representation); Product (the thing built).

Flow: the client chooses a ConcreteBuilder and gives it to the Director → the Director runs the steps in sequence → the client asks the builder for the finished product.

Builder vs. Abstract Factory: Builder builds one complex object step by step; Abstract Factory creates a family of related objects all at once.

The code-generator example as a picture. In: a messaging-specification document (message names, attributes, operations).

The code generator runs the same construction process for every language: open and read the file, find message names, attributes and operations, generate language-specific code, close the file.

Out: Java, C++ or C# code, i.e. different representations of the same messages. That combination (fixed process, varying output) is exactly the Builder’s use case.

Director with construct(): “this guy orchestrates the creational process”. It holds an AbstractBuilder and calls its steps in order.

«interface» AbstractBuilder with buildProductPartA/B/C(): these methods specify the multistep creational process for the product.

ConcreteBuilder must implement those creational methods, plus getProduct().

Product: the class being built; the ConcreteBuilder creates and assembles it. Creator classes = Director, AbstractBuilder, ConcreteBuilder; product class = Product.

0) Recognise a Builder problem: the same sequence of steps must give different final representations; a complex object is built step by step; construction should be hidden from the client and new variants easy to add.

1) Define the product: name what is built (Report, Burger, Form, House) and list its parts.

2) Declare the builder interface: the multistep API (buildPartA(...), buildPartB(...), getResult()). Steps say what to build, not how.

3) Implement concrete builders: one class per variant (PdfReportBuilder, HtmlReportBuilder), each storing intermediate state; getResult() returns the finished product.

4) Create the director (optional but recommended): a construct() method calls the steps in sequence, keeping the process reusable and consistent. 5) Client wiring: pick a ConcreteBuilder, pass it to the Director, call construct(), get the product.

6) Verify extensibility: a new variant needs only a new ConcreteBuilder; client and director stay unchanged.

The skeleton in Java:

Points to remember: product = the final object; builder interface = declares the steps; concrete builders = implement them differently; director = controls the order; client = chooses the builder. Same construction steps, different final representations.

The code-generator design. Director: CodeGenerator (generateCode()).

Abstract builder: MessageBuilder with the steps buildNewClass(name), buildClassAttributes(attributes), buildClassOperations(operations), closeClass(), getFileExtension(), plus getGeneratedProduct().

Concrete builders: CppMessageBuilder and JavaMessageBuilder implement every step for their language. The product is GeneratedProduct (addCode(), getCode(), getStats()…).

Note: getGeneratedProduct() was moved up into the abstract builder, because every language returns the same product type. That isn’t possible in every problem (if products differ per builder, each builder returns its own).

It separates construction from representation, so new representations (a C# builder) are added easily.

Existing representations change without touching the creational process (the director).

It gives finer control over construction: parts of an object are created at discrete points in time, unlike Abstract Factory, which creates each product in one call.

It improves maintainability, testability and reusability.

In simple words: use Builder when an object is created step by step instead of all at once, like ordering food where you pick bread, meat and sauce and the meal is assembled.

Without it: Burger("big bun", "double meat", "cheese", "ketchup", "lettuce"), a constructor with many parameters that is hard to read, hard to customise and easy to get wrong.

With it: new BurgerBuilder().addBun("Big Bun").addPatty("Beef").addCheese().addLettuce().addSauce("Ketchup").build();, each step named and optional. (This fluent, chained style is a common variant of Builder without a director.)

The exercise: a restaurant prepares Beef and Chicken burgers.

Every burger is prepared in the same sequence: add bun, add patty, add sauce.

The ingredients differ: beef = sesame bun + beef patty + BBQ sauce; chicken = whole-wheat bun + chicken patty + mayo.

Requirements: same steps for all burgers, new burger types easy to add, and the client chooses only the type while construction stays hidden: textbook Builder.

Tasks: draw the class diagram and write the Java (solution on slides 19–20).

The structure again, as the template for the burger answer: Director (Chef) → AbstractBuilder (BurgerBuilder) ← ConcreteBuilders (BeefBurgerBuilder, ChickenBurgerBuilder) → Product (Burger).

The solution:

5. The client:

A Veggie burger would need only a VeggieBurgerBuilder; Chef and the client logic stay unchanged.

Builder is an object creational pattern that encapsulates both the creational process and the representation of product objects.

In Abstract Factory, the various product objects are created all at once (one call each).

Builder lets clients control the multistep creational process of a single product.

It dictates the creation of individual parts at discrete points throughout the software’s operation.

The textbook example: a code generator works from an interface specification document (ICD) for custom hardware.

The company sells the hardware plus a library to monitor and control it. The generator reads the messaging specification and generates C++ classes that customers use with the hardware.

The ICD is complex, and customers now want Java and C# as well: the same generation process, new representations, so Builder.

The design (same as slide 14): CodeGenerator is the director, MessageBuilder the abstract builder, CppMessageBuilder and JavaMessageBuilder the concrete builders, GeneratedProduct the product. A C# version would add only a CSharpMessageBuilder.

The builder interface in C++:

The same steps are used to create products in every target language.

The C++ concrete builder, step by step (each step adds its code to the product with getGeneratedProduct()->addCode(...)).

Step 1 buildNewClass(name) writes class MessageOne {. Step 2 buildClassAttributes adds private: int attributeOne; int attributeTwo;. Step 3 buildClassOperations adds public: void setValueOne(unsigned char x);. Step 4 closeClass() writes };.

Result: a complete C++ class, the “C++ product created”. JavaMessageBuilder runs the same four calls and produces a Java class instead.

Singleton is an object creational pattern that prevents a class from being instantiated more than once in a running program.

Its intent: ensure a class has only one instance, and provide a global point of access to it.

The UML, member by member. -Singleton(): a private constructor (minus sign) restricts instantiation, so no other class can call new Singleton().

-instance : Singleton (underlined): a private static attribute that holds the one instance. Underlined members are static in UML.

+getInstance() : Singleton (underlined): a public static method that creates the instance if needed and gives everyone access to the one and only object. +operation() stands for the class’s ordinary behaviour.

The problem: an application needs event logging. Many objects generate events (actions, status, errors).

The design: one central event manager that every object uses. It creates an event list on instantiation, adds events as they are logged, and writes them to a file at specific points.

To prevent conflicts (two managers writing the same file), there must be only one instance of the event manager at any time: Singleton.

Why there is a problem: login, payment and notification systems all need to log. If each creates its own logger, you get multiple log files or conflicting writes, inconsistent data, and a system that is harder to debug and audit.

The real problem is conflicts, redundancy and loss of control.

Singleton fixes it: only one EventManager exists, every part shares it, so there is one log file and central control. One object → one responsibility → no conflict.

The example mapped onto the generic structure: EventManager has -instance_ : EventManager* (static), a private constructor -EventManager(), +getInstance(): EventManager* (static) and +logEvent(eventDescription: string).

Compared with the generic Singleton box, only the names changed: logEvent is the class’s real operation().

The Java class:

A static variable is allocated statically: it lives for the entire run of the program, which is why it can hold the single instance. Compare with the exam version (slide 27), which creates the instance lazily inside getInstance().

Using it:

1. Make the constructor private.

2. Define a private static attribute that stores a reference to the one instance.

3. Create a public static getInstance() method that uses the private constructor to create one object (if it doesn’t exist yet) and returns it to clients. These three steps are the whole answer to “write the Singleton code”.

Benefit: controlled access to a single instance of a type.

Benefit: it can be customised to allow a variable number of instances (e.g. a pool of at most N), since creation goes through one method.

Drawback: it doesn’t work well in multithreaded environments: two threads calling getInstance() at the same moment can both see instance == null and create two objects, unless the method is synchronised.

The scenario: a banking app’s login, transaction and notification systems all log events, and everything must go to one log in the correct order.

Step 1, the Singleton class:

Step 2, the login system: EventLogger.getInstance().log("User " + username + " logged in.");. Why not instance.log()? Because instance is private and static inside the class; from outside, getInstance() is the public way to reach the one object, and then you call .log() on it.

The transaction system logs "Transferred $" + amount + " from " + from + " to " + to through EventLogger.getInstance().log(...).

The notification system logs "Notification sent to " + user + ": " + message the same way.

The main class runs login, a transfer and a notification, then prints EventLogger.getInstance() == EventLogger.getInstance(), which is true: proof that all three systems used the same logger object.

The textbook EventManager in C++:

An extra exercise on the fifth creational pattern, Prototype: a drawing app needs many copies of Circle (radius) and Square (side).

New shapes should be created by copying existing ones instead of from scratch.

Tasks: draw the class diagram; write Java with a common interface, a self-copy method in each shape, and a main that copies a Circle and a Square.

The plan: a Prototype interface with clone(), concrete prototypes Circle and Square, and a client that clones instead of calling new.

Step 1:

Step 2:

Step 3:

Step 4, the client:

Key idea: a clone is an identical but separate copy (c1 and c2 have equal state but are different objects). With nested mutable fields, decide between shallow and deep copies.

This lecture: Builder and Singleton (plus a Prototype exercise), completing the creational patterns.

Next: structural and behavioural design patterns (Chapter 7).