SOLID principles
beginnerSingle Responsibility Principle (SRP)
A class should have one, and only one, reason to change.
The Single Responsibility Principle, the "S" in SOLID, states that a class should have one and only one reason to change. Robert Martin's sharper phrasing is that a class should be responsible to a single actor — a single source of requirements or stakeholder. When a class serves two actors, a change demanded by one risks breaking behaviour relied on by the other, and the two responsibilities become entangled in the same code.
A restaurant kitchen: the chef cooks, the sommelier picks wine, the dishwasher cleans. One person doing all three serves customers slowly and badly.
Key Concepts
1
The usual symptom is a class that mixes concerns from different axes of change: a User class that holds user data, formats it as HTML, and also persists it to a database is answerable to the presentation team, the persistence team, and the domain — three reasons to change living in one place. Splitting it so that the entity holds data, a separate formatter renders it, and a repository persists it gives each its own reason to change. The benefits are concrete: smaller, focused classes are easier to understand, test in isolation, and reuse, and a change to formatting rules can no longer accidentally break persistence.
User
2
The principle is easy to over- or under-apply, which is where judgement and interview discussion come in. "One responsibility" does not mean one method per class — it means one cohesive reason to change — and chopping every class into trivial fragments produces its own kind of unmaintainable sprawl. The practical test is to ask who would request a change to this class; if you can name two different roles or stakeholders, the responsibilities probably want separating. SRP underpins the rest of SOLID, because cohesive, single-purpose classes are what make extension and substitution tractable.