What does the Single Responsibility Principle actually mean?
Assesses fundamental understanding of OOP Concepts conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
The Single Responsibility Principle states that a class should have one reason to change, meaning it should serve one actor or concern. It is about change, not size: a small class can still have two reasons to change if it mixes two concerns.
A class that loads an order from a database, calculates tax, formats an invoice and sends email has four reasons to change. A database change, a tax rule change, a layout change and an email provider change each force edits to the same file.
class Order { BigDecimal total() { ... } }
class TaxCalculator { BigDecimal forOrder(Order o) { ... } }
class InvoiceRenderer { String render(Order o) { ... } }
class EmailSender { void send(Invoice i) { ... } }
The payoff is easier testing, clearer ownership and a smaller blast radius when requirements change. Applied dogmatically it can produce hundreds of anemic classes, so group responsibilities that genuinely change together for the same reason.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.