Add code examples, and documentation
This commit is contained in:
37
docs/principles.md
Normal file
37
docs/principles.md
Normal file
@@ -0,0 +1,37 @@
|
||||
[← Design patterns index](README.md)
|
||||
|
||||
# Principles these examples keep demonstrating
|
||||
|
||||
These seven patterns all apply the same handful of ideas from _Dive Into Design
|
||||
Patterns_' design-principles chapter:
|
||||
|
||||
- **Encapsulate what varies.** Each pattern isolates the one thing that changes:
|
||||
the platform (Bridge), the added behavior (Decorator), the subsystem wiring
|
||||
(Facade), the collaboration rules (Mediator), the saved state (Memento), the
|
||||
reaction to a change (Observer), or the state-specific behavior (State).
|
||||
Everything else stays untouched.
|
||||
|
||||
- **Program to an interface, not an implementation.** `IMessageSender`,
|
||||
`IShape`, `IObserver`, `IMemento`, `IOriginator`, and `State` all exist so
|
||||
that a context or client depends on a contract instead of a concrete type.
|
||||
`Subject.Notify()` calls `observer.Update()` through `IObserver` alone, which
|
||||
is exactly why `Data` never needs to know that `PieChart` or `BarGraph`
|
||||
exists.
|
||||
|
||||
- **Favor composition over inheritance.** Bridge, Decorator, Mediator, and State
|
||||
all answer "my class hierarchy is exploding" the same way: give the object a
|
||||
_reference_ to another object instead of subclassing again. Shvets: _"with
|
||||
composition you can easily substitute the linked 'helper' object with another,
|
||||
changing the behavior of the container at runtime."_
|
||||
|
||||
- **Single Responsibility.** _"A class should have just one reason to change."_
|
||||
Visible in `ShapeDecorator` subclasses (one behavior each), the `State`
|
||||
subclasses (one state each), and `Facade` (all engine sequencing in one
|
||||
place).
|
||||
|
||||
- **Open/Closed.** _"Classes should be open for extension but closed for
|
||||
modification."_ The concrete test: adding a new `IObserver`, a new
|
||||
`ShapeDecorator`, a new `IMessageSender`, or a new `State` requires **zero**
|
||||
edits to existing classes. Adding a state to `BadCarState` requires editing
|
||||
four separate `switch` statements — that's the principle failing, made
|
||||
visible.
|
||||
Reference in New Issue
Block a user