The Single Responsibility Principle (SRP) is the most misunderstood of the SOLID principles. Developers hear "a class should do one thing" and create classes with a single method. That is not what SRP means. SRP says: a class should have one reason to change. The word "reason" refers to a stakeholder: a person or group who would request a change.

Why does this matter? Because when a class has multiple reasons to change, modifying it for one reason risks breaking it for another. A UserService that validates input, saves to a database, and sends welcome emails will change when the validation rules change, when the database schema changes, and when the email template changes. Three different stakeholders, three different change triggers, all in one class. A bug fix in the email template accidentally breaks database persistence. A schema migration corrupts the validation logic.

The God Class Anti-Pattern

The opposite of SRP is the god class, a class that knows everything and does everything. God classes are seductive because they are easy to write. Need to add a feature? Just add a method to the god class. But they become maintenance nightmares:

This class has at least five responsibilities: input validation, password hashing, database persistence, cache management, email sending, and report generation. Six different reasons to change, six different stakeholders who might request changes.

SRP Is About People, Not Code

Robert Martin, who formulated SRP, clarified that "reason to change" maps directly to stakeholders. The database team wants to change the persistence logic. The security team wants to change the password hashing algorithm. The marketing team wants to change the welcome email template. If these are different people with different schedules and priorities, their concerns should live in different classes.

When concerns are separated, changes are isolated. The marketing team updates the email template without touching persistence code. The database team changes the schema without risking the email system. Each team modifies only the class that belongs to their domain, and other teams are unaffected.

What "One Responsibility" Actually Looks Like

A class following SRP has a clear, single-sentence description of its purpose:

• UserValidator, validates user input against business rules
• UserRepository, persists and retrieves user data from the database
• PasswordHasher, hashes and verifies passwords
• WelcomeEmailer, sends welcome emails to new users
• UserReportGenerator, produces user reports in various formats

Each class has one reason to change, one stakeholder, and one area of expertise. When you read the class name, you know exactly what it does and, equally important, what it does not do.