What are Design Patterns?

A design pattern is a general, reusable solution to a commonly occurring software design problem — a named vocabulary for a proven structural idea, not literal code you copy in. They were originally catalogued (23 patterns) by the “Gang of Four” (Gamma, Helm, Johnson, and Vlissides) in their 1994 book Design Patterns: Elements of Reusable Object-Oriented Software.

What the Tripos expects

For each pattern the Tripos covers, you should be able to:

1. Name the abstract problem it solves.
2. Sketch the structure (roles, relationships, participants).
3. Connect it back to OCP or another design principle.
4. Apply it to a specific scenario, writing concrete code for the scenario’s classes and methods.

Critical tip for Tripos answers: Always tie the pattern back to the SPECIFIC classes and methods in the scenario, not just quote a generic description. The examiner wants to see you can apply the pattern, not just recite it.

What patterns are NOT

Not algorithms

Patterns are about design structure (how classes relate and collaborate). Algorithms are about computation steps (how to sort, search, or compute). An algorithm is often used inside a pattern’s methods, but the pattern itself describes the scaffolding.

Not libraries

Libraries are concrete, reusable code you import and call. Patterns are conceptual templates you adapt and implement in your own context. You cannot import a Singleton — you write it tailored to your specific class.

Why patterns matter

1. Shared vocabulary — “Just use Observer here” communicates the entire design intent in two words. No need to explain the whole notification mechanism every time.
2. Proven solutions — Patterns encode decades of object-oriented design experience. You do not have to reinvent the wheel for each project.
3. Teaching tool — Patterns distil design knowledge into named, digestible chunks. Learning patterns teaches you to recognise design problems and their standard solutions.

Patterns the Tripos focuses on

Pattern	Essence	Principle connection
Composite	Treat one object and a group of objects uniformly through a shared interface	OCP — new leaf types slot in
Decorator	Add behaviour to an individual object dynamically by wrapping	OCP — new decorators without changing existing classes
State	Object changes its behaviour when its internal state changes	SRP — each state’s behaviour in its own class
Strategy	Select between interchangeable algorithms at runtime	OCP — new strategies without modifying client
Singleton	Ensure exactly one instance with global access	(Often criticised for violating SRP)
Observer	Notify many dependents automatically when state changes	Loose coupling — subject knows only the Observer interface

How to answer pattern questions

1. Identify the problem in the scenario the question describes.
2. Name the pattern that addresses it (be explicit: “The Composite pattern”).
3. Sketch the structure — which interfaces, which concrete classes, what the relationships are.
4. Write the code — adapt the pattern template to the scenario’s specific domain classes.
5. Justify — explain what problem would arise without the pattern, and how the pattern resolves it. Connect to OCP, loose coupling, or whichever principle is relevant.