How do you define the responsibilities of each class in an LLD?
Fast recall
Quick revision
Core answer
Ability to apply the Single Responsibility Principle in practice — assigning clear, focused responsibilities to each class without overlap or confusion.
Creating god classes that handle everything (ParkingLot manages spots, calculates fees, generates tickets, processes payments) or splitting responsibilities too finely into trivial classes.
Mention that you'd validate responsibilities by asking 'what would cause this class to change?' — if there are multiple unrelated answers, the class needs splitting.
Interview-ready guide
Interview answer
I define responsibilities using the Single Responsibility Principle, which says a class should have exactly one reason to change. The practical test I use is to state the class's job in a single sentence, and if I find myself using the word and, that's a red flag. If I say ParkingSpot tracks occupancy and calculates the fee and prints the ticket, that's three responsibilities wearing one class, and each is a separate reason the class might change — occupancy rules, pricing, ticket formatting.
So I'd split that into focused classes. ParkingSpot just manages its own state — occupied or free. A FeeCalculator computes the charge. A TicketPrinter handles formatting and output. Now each class has one cohesive job, which means when pricing changes I only touch FeeCalculator, and I can unit-test it without dragging in a parking spot.
The big anti-pattern this avoids is the God class — some Manager that knows everything and is impossible to test or reason about. But I'd also caution against the opposite extreme: splitting so aggressively that you end up with dozens of anaemic one-method classes, which fragments the logic and hurts readability just as much. The target is high cohesion — everything in a class genuinely belongs together and serves the same single purpose. That balance is what makes a design both clean and practical.
For example, when a parking ticket closes, ParkingSpot changes its occupancy, FeeCalculator computes the amount, and TicketPrinter formats the receipt. A small exit service coordinates those objects without taking ownership of their rules.
How do you define the responsibilities of each class in an LLD
Direct Answer
Apply the Single Responsibility Principle: each class should have one reason to change. ParkingSpot manages spot state and availability. FeeCalculator computes parking fees based on time and vehicle type. TicketGenerator creates and validates tickets. Avoid combining unrelated behaviors in one class.
Deep Dive & Architecture
A responsibility is a reason to change
Class boundaries should follow business responsibilities, not merely the nouns in the prompt. ParkingSpot changes when occupancy rules change, FeeCalculator changes when pricing changes, and TicketFormatter changes when the printed or digital ticket format changes. Those are separate sources of change, so they belong in separate classes.
Objects collaborate through small contracts
When a vehicle exits, an exit service reads the ticket, asks the fee calculator for the amount, records payment, and tells the spot to vacate. The service coordinates the use case, but it does not take over the state or calculation owned by those objects. Small interfaces make each collaborator replaceable in tests.
Cohesion prevents both extremes
A class is cohesive when its fields and methods support one clear purpose. A God class mixes unrelated rules and becomes hard to test. The opposite extreme—creating a new class for every one-line operation—scatters the model. The useful boundary keeps rules that change together in one place and separates rules that change for different reasons.
Common Mistakes & Pitfalls
- The God class — a
Managerthat does everything; impossible to test in isolation. - Mixing layers — persistence + business rules + formatting in one class.
- Confusing SRP with "one method" — a class can have many methods serving one responsibility.
- Splitting too far — anaemic one-method classes everywhere also hurts; aim for cohesion.
Check your understanding
Answer these without looking back at the article.
- What are enums useful for in LLD and how do you use them?
- How do you model a one-to-many relationship in LLD Java classes?
- What is the difference between an abstract class and an interface in LLD?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.