Topic 3.3
Responsibility Assignment
In one line
The single most important LLD skill: deciding which class owns which behavior — and keeping responsibilities from bleeding across classes.
Think of it like this
A restaurant. The chef cooks, the waiter serves, the cashier bills. If the waiter starts cooking and billing too, everything slows down and mistakes pile up. Every class should have one clear job.
Key ideas
- 01
Ask: 'who knows X best?' — pricing lives with the pricing policy, not the parking lot.
- 02
Ask: 'who will change when X changes?' — that class owns X (SRP by change-reason).
- 03
Split behavior from data orchestration: domain entity computes, service class orchestrates.
- 04
Testability signals: if a behavior needs 5 collaborators, it's probably in the wrong class.
- 05
Tell-don't-ask: give an object its data and let it behave, instead of pulling state out and deciding elsewhere.
- 06
Interview habit: narrate 'ParkingSpot owns its occupied state; ParkingLot assigns spots; TicketOffice prices'.
Java / Spring map
- →
Spring layering: Controller (transport) → Service (orchestration) → Domain (behavior) → Repository (persistence).
Explain without notes
Who owns fee calculation when pricing depends on spot type AND vehicle type — and why?
Practice
Refactor an anemic ParkingLot with all logic in one class into entities + a service.
Trade-offs
- ↔
Over-moved logic = anemic; under-moved = God class. This line is the craft.
Completion checklist
I can assign each use case to an owning class and defend it in one sentence.