Single Responsibility
A module should have one coherent reason to change. Identify the stakeholders and policies that drive changes; counting methods does not reveal whether a responsibility is cohesive.
What you’ll understand
- A module should have one coherent reason to change. Identify the stakeholders and policies that drive changes; counting methods does not reveal whether a responsibility is cohesive.
- Separate the calculation responsibility from rendering so each can change and be tested independently.
- Evaluate the tradeoff: Splitting too finely creates coordination overhead. Keep operations together when the same business rule and stakeholder govern them.
Useful first: Classes and Objects
The idea and when to recognize it
A module should have one coherent reason to change. Identify the stakeholders and policies that drive changes; counting methods does not reveal whether a responsibility is cohesive.
- Requirement: A sales report changes when either accounting rules or presentation requirements change.
- Change to anticipate: Introduce a new output format while leaving the arithmetic untouched.
- Design goal: Separate the calculation responsibility from rendering so each can change and be tested independently.
Start with the concrete problem
A sales report changes when either accounting rules or presentation requirements change.
Introduce a new output format while leaving the arithmetic untouched.
| Direct implementation | Revised design |
|---|---|
| A report class that calculates, formats, and persists everything has several unrelated reasons to change. | Separate the calculation responsibility from rendering so each can change and be tested independently. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Splitting too finely creates coordination overhead. Keep operations together when the same business rule and stakeholder govern them. |
Responsibilities and contracts
Separate the calculation responsibility from rendering so each can change and be tested independently.
- Calculator: Produces numeric results. Public operations: sum(values)
- Renderer: Chooses output representation. Public operations: render(total)
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
An invoice service can delegate persistence to a repository without moving every arithmetic expression into its own class.
- 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
Splitting too finely creates coordination overhead. Keep operations together when the same business rule and stakeholder govern them.
Common mistake: A report class that calculates, formats, and persists everything has several unrelated reasons to change.
- Explain the choice: Separate the calculation responsibility from rendering so each can change and be tested independently.
- Challenge your choice: Splitting too finely creates coordination overhead. Keep operations together when the same business rule and stakeholder govern them.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…