Question 11 of 11: Design Patterns, Their Description and the GoF Categories

Question 11: Design Patterns, Their Description and the GoF Categories (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) What Design Patterns Are, Their Origin, and Reusability

A design pattern is a named, general, reusable solution to a design problem that recurs across many different systems within a given context — it captures a proven approach rather than a specific block of code. Design patterns originate from experienced designers' observation that certain design problems, and certain good solutions to them, appear again and again across otherwise unrelated systems; the idea was first catalogued for software by the "Gang of Four" (Gamma, Helm, Johnson and Vlissides), drawing inspiration from Christopher Alexander's earlier work cataloguing recurring patterns in building architecture. Their relationship to reusability is subtle: a pattern reuses a proven design, not literal code — it lets designers reuse accumulated experience and a shared vocabulary ("put an Observer here") rather than re-deriving a solution to a well-understood problem from first principles each time, which both speeds development and raises confidence in the resulting design's quality.

(b) The Eleven Parts of a Pattern Description

Intent states what the pattern does and which design problem it solves. Motivation gives a concrete scenario illustrating the problem and how the pattern's structure resolves it. Applicability lists the conditions under which the pattern should be used. Structure is a diagram, typically UML, showing the pattern's classes and their relationships. Participants lists the classes or objects involved and the responsibility each one plays. Collaborations describes how the participants interact to fulfil their responsibilities. Consequences weighs the trade-offs, costs and benefits of applying the pattern. Implementation notes pitfalls, hints and language-specific techniques for coding it. Sample code gives an illustrative fragment showing the pattern implemented in a real language. Known uses cites examples of the pattern found in real, existing systems. Related patterns names other patterns commonly used alongside, or as an alternative to, this one.

(c) The Three GoF Categories

Creational patterns address how objects are created, decoupling client code from the concrete classes it must instantiate so the client can be written against an abstraction rather than a specific constructor call — the Singleton pattern is one example, ensuring a class has only one instance and providing a single global point of access to it. Structural patterns address how classes and objects are composed into larger structures while keeping that structure flexible and efficient — the Adapter pattern is one example, converting the interface of an existing class into another interface a client expects, without modifying the original class. Behavioral patterns address how objects communicate and how responsibility is distributed among them at runtime — the Observer pattern is one example, letting one object (the subject) notify a dynamic list of dependent objects automatically whenever its state changes. The three categories are therefore distinguished by which design concern they solve: object creation, object/class composition, or inter-object communication and responsibility.

Practical Application

A GUI toolkit is a natural home for all three at once: a Singleton (creational) manages the single application-wide theme manager, an Adapter (structural) lets a legacy rendering library be used behind the toolkit's modern drawing interface, and an Observer (behavioral) lets any number of widgets be notified automatically when the theme manager's colour scheme changes.