Open/Closed
Keep stable policy closed to repeated modification while allowing a known variation point to be extended. Choose that boundary from actual change pressure rather than anticipating every possible extension.
What you’ll understand
- Keep stable policy closed to repeated modification while allowing a known variation point to be extended. Choose that boundary from actual change pressure rather than anticipating every possible extension.
- Extend shipping behavior through a collaborator that already satisfies the fee contract.
- Evaluate the tradeoff: Every system still needs edits when requirements change. The goal is to protect a useful stable boundary, not to promise that no existing line will ever change.
Useful first: Classes and Objects
The idea and when to recognize it
Keep stable policy closed to repeated modification while allowing a known variation point to be extended. Choose that boundary from actual change pressure rather than anticipating every possible extension.
- Requirement: A checkout’s shipping choice changes more often than its subtotal calculation.
- Change to anticipate: Support an express delivery policy without changing checkout’s total method.
- Design goal: Extend shipping behavior through a collaborator that already satisfies the fee contract.
Start with the concrete problem
A checkout’s shipping choice changes more often than its subtotal calculation.
Support an express delivery policy without changing checkout’s total method.
| Direct implementation | Revised design |
|---|---|
| Adding another carrier branch to checkout for each new fee policy spreads variation into stable code. | Extend shipping behavior through a collaborator that already satisfies the fee contract. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Every system still needs edits when requirements change. The goal is to protect a useful stable boundary, not to promise that no existing line will ever change. |
Responsibilities and contracts
Extend shipping behavior through a collaborator that already satisfies the fee contract.
- Checkout: Combines prices through a stable operation. Public operations: total(items)
- ShippingPolicy: Hides fee selection. Public operations: fee()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A discount engine can accept a new discount strategy while preserving its application sequence.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Every system still needs edits when requirements change. The goal is to protect a useful stable boundary, not to promise that no existing line will ever change.
Common mistake: Adding another carrier branch to checkout for each new fee policy spreads variation into stable code.
- Explain the choice: Extend shipping behavior through a collaborator that already satisfies the fee contract.
- Challenge your choice: Every system still needs edits when requirements change. The goal is to protect a useful stable boundary, not to promise that no existing line will ever change.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…