CAIE 9618 · Paper 4 · Topic 4.2.2

Design
Patterns

Reusable Solutions to Common Problems · Observer · Singleton · Strategy · Factory

CSZone Cambridge International AS & A Level Computer Science 9618

What are Design Patterns?

Proven Templates for Common Problems

Design patterns are reusable, named solutions to recurring software design problems. They are not finished code — they are templates or best-practice approaches that describe how to structure classes and objects to solve a common problem efficiently.

WHY USE DESIGN PATTERNS?

Provide a proven solution — reduces the risk of introducing bugs

Improve code readability — experienced developers recognise named patterns immediately

Encourage reuse — separates concerns so components can be swapped independently

Language-agnostic — patterns apply across OOP languages

THREE CATEGORIES (Gang of Four)

Creational — how objects are created (Factory, Singleton)

Structural — how classes/objects are composed (Adapter, Decorator)

Behavioural — how objects communicate and behave (Observer, Strategy)

CAIE 9618 focuses on: Observer, Singleton, and Strategy as the most examinable patterns.

Observer Pattern

One-to-Many Notification System

The Observer pattern defines a one-to-many relationship between objects. When the Subject (publisher) changes state, it automatically notifies all registered Observers (subscribers), which update themselves accordingly.

STRUCTURE

Subject (Observable) — maintains a list of observers; has RegisterObserver(), RemoveObserver(), NotifyAll() methods

Observer interface — defines the Update() method all observers must implement

Concrete Observers — implement Update(); react to state change in their own way

REAL-WORLD EXAMPLES

News feed: subscribers are notified when a new article is published

Stock ticker: all connected displays update when a stock price changes

GUI event handling: button click notifies all registered event listeners

BENEFITS

Loose coupling — Subject doesn't need to know the concrete type of its Observers; it only knows they implement the Observer interface

Observers can be added/removed at runtime without changing the Subject

Subject and Observers can vary independently — new observer types don't require changes to the subject

Singleton & Strategy Patterns

Creational & Behavioural

Singleton Pattern

Ensures only ONE instance of a class ever exists and provides a global access point to it.

Constructor is PRIVATE — prevents external instantiation with NEW

A static GetInstance() method checks if an instance exists — returns existing one or creates it

Use cases: database connection pool, logger, configuration manager, print spooler

Drawback: global state makes testing harder (difficult to mock)

Strategy Pattern

Defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime.

Context class holds a reference to a Strategy interface

Concrete strategies (e.g. BubbleSort, QuickSort) implement the interface

The algorithm used can be swapped at runtime without changing the Context

Use cases: sorting algorithms, payment method selection, route calculation, compression method

Benefit: eliminates if-else chains for choosing algorithm; open-closed principle

Exam Practice

Cambridge-style questions

Question 1

A weather monitoring system has a WeatherStation class that collects temperature data. Multiple displays (PhoneDisplay, DesktopDisplay) need to update whenever the temperature changes. State which design pattern is most suitable and explain how it would be applied to this scenario. [4]

1

The Observer pattern is most suitable — it handles one-to-many notification where one object's state change triggers updates in multiple dependents.

1

WeatherStation acts as the Subject — it maintains a list of registered Observer objects and calls NotifyAll() when the temperature data changes.

1

PhoneDisplay and DesktopDisplay are Concrete Observers — they implement the Observer interface (with an Update() method) and register themselves with the WeatherStation.

1

Benefit: WeatherStation does not need to know the types of the displays — it only calls Update() on each observer. New display types can be added without modifying WeatherStation (loose coupling).

Common Mistakes

Don't lose easy marks

1

Saying "the Singleton pattern is the best OOP approach" — Singletons introduce global state which makes code harder to test and maintain. Exam questions often ask for a limitation of Singleton — always mention the testing difficulty / global state issue.

2

Confusing Observer (notification) with Singleton (one instance) — they solve completely different problems. Observer = one-to-many communication; Singleton = single shared instance of a class. Identify the pattern from the problem description, not just by name-dropping.

3

Not explaining WHY a pattern is used — CAIE mark schemes always award marks for the stated benefit (e.g. "loose coupling" for Observer, "prevents multiple instances" for Singleton). Identifying the pattern name alone rarely earns full marks.

Topic Summary — 4.2.2

What You Need to Know

OBSERVER

Subject notifies all registered observers when state changes. One-to-many. Loose coupling — Subject only knows Observer interface. Register/Remove/NotifyAll. Use: event systems, live data feeds.

SINGLETON

One instance only. Private constructor. Static GetInstance(). Global access point. Use: logger, config, DB connection. Limitation: global state, hard to test.

STRATEGY

Encapsulate family of algorithms. Context holds Strategy reference. Swap algorithms at runtime. Use: sort method, payment type, compression. Benefit: open-closed principle, no if-else chains.

CSZone

Next Video

4.2.3

Exception Handling

TRY · EXCEPT · Throwing Exceptions · Custom Exceptions

Head to CSZone.co.uk for the complete worksheet, quiz, and interactive tools