Dependency
A dependency is a temporary use of another abstraction to perform an operation. It is weaker than storing a long-lived association and should point from the user toward what it needs.
What you’ll understand
- A dependency is a temporary use of another abstraction to perform an operation. It is weaker than storing a long-lived association and should point from the user toward what it needs.
- Pass a policy through the checkout boundary and call its fee operation only when calculating a total.
- Evaluate the tradeoff: Dependency arrows help locate change impact, but drawing an arrow does not remove coupling. Keep parameter and return contracts narrow.
Useful first: Classes and Objects
The idea and when to recognize it
A dependency is a temporary use of another abstraction to perform an operation. It is weaker than storing a long-lived association and should point from the user toward what it needs.
- Requirement: A checkout needs a shipping calculation during total computation.
- Change to anticipate: Replace the calculation without making checkout know the carrier’s internal rules.
- Design goal: Pass a policy through the checkout boundary and call its fee operation only when calculating a total.
Start with the concrete problem
A checkout needs a shipping calculation during total computation.
Replace the calculation without making checkout know the carrier’s internal rules.
| Direct implementation | Revised design |
|---|---|
| Copying the fee into checkout makes a temporary collaboration into duplicated policy. | Pass a policy through the checkout boundary and call its fee operation only when calculating a total. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Dependency arrows help locate change impact, but drawing an arrow does not remove coupling. Keep parameter and return contracts narrow. |
Responsibilities and contracts
Pass a policy through the checkout boundary and call its fee operation only when calculating a total.
- 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 report renderer can receive a formatter for one render call rather than own a global formatter.
- 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
Dependency arrows help locate change impact, but drawing an arrow does not remove coupling. Keep parameter and return contracts narrow.
Common mistake: Copying the fee into checkout makes a temporary collaboration into duplicated policy.
- Explain the choice: Pass a policy through the checkout boundary and call its fee operation only when calculating a total.
- Challenge your choice: Dependency arrows help locate change impact, but drawing an arrow does not remove coupling. Keep parameter and return contracts narrow.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…