A design pattern is a named, reusable solution structure for a recurring software design problem. Its core solution can be reused without repeating the implementation exactly, helping designs adapt as software changes. section 9.1.3 section 9.0
Patterns are not tied to one programming language. Implementations change with languages and frameworks; Java 8, for example, enables different implementations through functional-style programming. section 9.1.3
Common patterns connect reusable structures with broader design principles:
- Singleton centralizes state by ensuring one class instance and a global access point. section 9.1.3
- Builder separates complex object construction from representation and supports step-by-step configuration. section 9.1.3
- Strategy encapsulates interchangeable algorithm families, allowing new behavior without changing existing code. section 9.1.3
- Circuit Breaker addresses distributed-system resilience. section 9.1.3
A condition-heavy calculation
A shipping calculation branches across express delivery, holidays, international orders, and country codes. Such recurring design problems are candidates for a named reusable structure rather than repeated ad hoc logic. section 9.1.3
Table 9.2 Useful design patterns
|
Pattern
|
Description
|
Relation to SOLID principles
|
|---|---|---|
|
Singleton
|
Ensures only one instance of a class exists and provides a global access point.
|
Supports the Single Responsibility Principle by centralizing state.
|
|
Builder
|
Separates object construction from its representation, allowing step-by-step creation of complex objects. See example in chapter 4.
|
Supports the Open/Closed Principle by allowing new configurations without modifying existing code.
|
|
Strategy
|
Defines a family of algorithms, encapsulates each one, and makes them interchangeable at runtime. See example in chapter 3.
|
Exemplifies the Open/Closed and Dependency Inversion principles by encapsulating algorithms behind a common interface and allowing new behaviors without changing existing code.
|
|
Factory
|
Encapsulates object creation logic, delegating instantiation to dedicated classes.
|
Demonstrates the Dependency Inversion Principle by decoupling high-level code from specific implementations and supporting the Open/Closed Principle by allowing new objects to be created without modifying existing code.
|
|
Decorator
|
Dynamically adds new behavior to objects without modifying their code. See example in chapter 7.
|
Supports the Open/Closed Principle by adding behavior to an object without altering its source code.
|
|
Observer
|
Establishes a one-to-many relationship where objects automatically update when a subject changes.
|
Demonstrates the Open/Closed and Dependency Inversion principles by letting subjects and observers interact through abstractions, allowing new observers without modifying existing code.
|
Compare well-known patterns with their descriptions and relationships to SOLID principles. section 9.1.3
