Introduction to Design Patterns
A design pattern names a recurring arrangement of responsibilities and its tradeoffs. Recognizing the problem is more valuable than reproducing a class diagram from memory.
What you’ll understand
- A design pattern names a recurring arrangement of responsibilities and its tradeoffs. Recognizing the problem is more valuable than reproducing a class diagram from memory.
- Practice explaining a design decision with an example and a boundary case.
Three families of design decisions
Creational patterns organize how objects are constructed. Structural patterns organize how objects are connected or wrapped. Behavioral patterns organize how operations, policies, and state changes are distributed. A pattern can participate in several concerns, but its intent determines its usual family.
- Builder separates a construction process from its finished value.
- Adapter translates an incompatible client contract.
- Observer organizes registration and notification.
Start with the pressure to change
First implement the simplest correct behavior. Then introduce a concrete change: a second provider, a new algorithm, or an undo requirement. Identify which stable code should be protected from that change. If the proposed abstraction cannot explain what it isolates, it may be unnecessary.
- Name the client and the variation point.
- Compare at least one simpler alternative.
- State the cost in objects, indirection, or stored history.
Compare intent, not just arrows
Adapter and Decorator both wrap objects, but one changes a contract and the other preserves it while adding behavior. Strategy and State both delegate, but a strategy is a chosen policy while state behavior follows a lifecycle. The surrounding use case resolves the ambiguity.
- What is allowed to vary independently?
- Who chooses or changes the collaborator?
- What public behavior must stay stable?