| Lesson 3 | What Is a Design Pattern? |
| Objective | Recognize a design pattern as a reusable design description, not copied code or a guaranteed solution. |
What Is a Software Design Pattern?
A software design pattern names a recurring design problem, describes the forces that make the problem difficult, and records a reusable arrangement of collaborating objects. It is a design vocabulary rather than a finished implementation. Developers still have to adapt the pattern to the language, constraints, and behavior of their application.
Patterns are useful because they make design intent visible. Saying that a service uses an Observer, for example, conveys more than saying that one object calls several others: it signals that observers subscribe to a subject and are notified when relevant state changes.
Pattern, Algorithm, and Framework
| Concept | What it provides | What the developer supplies |
|---|---|---|
| Algorithm | A finite procedure for computing a result | Inputs and an implementation in a programming language |
| Design pattern | Roles, collaborations, consequences, and implementation guidance | Application-specific classes, policies, and trade-offs |
| Framework | Reusable executable code with extension points | Components that plug into the framework lifecycle |
How Abstraction Supports Reuse
An abstract data type specifies operations independently of representation. A list, for example, may be backed by an array or a linked structure while exposing comparable operations. A design pattern works at a broader level: it abstracts a collaboration among responsibilities.
Consider Strategy. A context delegates a variable behavior to a strategy interface. The concrete strategies can change without forcing the context to contain every algorithm in one conditional block. The value comes from the dependency boundary, not merely from creating more classes.
A Pattern Includes Consequences
A pattern is not automatically the best choice. Applying one may add indirection, objects, configuration, or lifecycle concerns. A responsible pattern decision therefore answers four questions:
- Context: What part of the system is changing or difficult to couple safely?
- Forces: Which requirements compete with one another?
- Structure: Which objects own the responsibilities and how do they collaborate?
- Consequences: What flexibility is gained, and what complexity or runtime cost is introduced?
If a problem is simple and unlikely to vary, a direct implementation can be clearer than a pattern. Patterns earn their keep when their structure makes an important source of change easier to control.
Example: Traffic-Signal Messages
In the course project, different signal types display different messages for the same logical state. A common TrafficSignal abstraction can define the legal state transition, while TrafficLight and WalkSign supply their own messages. This is a small example of separating stable policy from behavior that varies.
The example does not prove that inheritance is always preferable. A later design might inject a message strategy instead. Comparing those alternatives is exactly the kind of trade-off analysis that pattern study is meant to develop.