Definition — A Class Should Have One Reason to Change - What Is Srp | OneNoughtOne

0/246

System Design (LLD)Single Responsibility Principle

What Is SRP?

LevelIntermediate

Duration55 mins

TopicSingle Responsibility Principle

1 / 4

Definition — A Class Should Have One Reason to Change

The First Principle of Good Design

Of all the principles that guide object-oriented design, the Single Responsibility Principle (SRP) stands as the most fundamental—and paradoxically, the most misunderstood. Its statement appears deceptively simple: A class should have only one reason to change. Yet hidden within this brief sentence lies a profound insight that separates well-architected software from tangled, fragile codebases that resist every modification.

When you encounter code that makes you nervous to change—where fixing a bug in one place mysteriously breaks functionality elsewhere—you're almost certainly witnessing an SRP violation. When you inherit a codebase where seemingly simple features require modifications across dozens of files, SRP was abandoned long ago. And when you discover that testing a single class requires mocking half the system, SRP was never considered at all.

The Single Responsibility Principle is not merely one of five SOLID principles; it is the foundation upon which all other principles rest. Without SRP, the Open/Closed Principle becomes impossible—you cannot extend what you cannot isolate. Without SRP, the Liskov Substitution Principle becomes meaningless—substitutability assumes coherent behavioral contracts. Without SRP, the Interface Segregation Principle has nothing to segregate. And without SRP, Dependency Inversion has no clear abstractions to invert toward.

What You Will Learn

By the end of this page, you will understand the precise definition of the Single Responsibility Principle, why 'one reason to change' is fundamentally about cohesion and stakeholders, how to recognize classes that violate SRP, and why this principle is not about limiting classes to a single method or a simple task—but about ensuring each class serves a single, coherent purpose that changes for a single, identifiable reason.

The Formal Definition

The Single Responsibility Principle was introduced by Robert C. Martin (Uncle Bob) as part of the SOLID principles. Its canonical statement is:

A class should have one, and only one, reason to change.

This statement requires careful unpacking. Notice that SRP does not say:

A class should have only one method
A class should do only one thing
A class should be small

These are common misconceptions that lead developers astray. Instead, SRP speaks of reasons to change—a concept that connects directly to the forces that drive software evolution.

What is a 'reason to change'?

A reason to change is a business or technical force that might require you to modify the class. Consider a class that:

Formats employee data for reports
Calculates employee salaries
Stores employee records in a database

This class has three reasons to change:

Report format requirements change (presentation tier evolves)
Salary calculation rules change (business logic evolves)
Database schema changes (persistence tier evolves)

Each of these changes originates from a different source—different stakeholders, different concerns, different rates of change. When they're bundled into a single class, a change to any one aspect risks affecting the others.

The Coupling Insight

SRP is fundamentally about managing coupling. When a class has multiple responsibilities, those responsibilities become coupled through the shared class. A change to one responsibility forces recompilation, retesting, and redeployment of code for all other responsibilities—even when they haven't changed. SRP breaks this coupling by separating concerns into distinct classes.

The key insight: Reasons to change come from people

Uncle Bob later refined the SRP definition to explicitly connect reasons to change with actors—the people or groups who request changes:

A module should be responsible to one, and only one, actor.

An actor is a person or group that serves as a single source of change. The CFO might drive changes to financial calculations. The DBA might drive changes to persistence logic. The UX team might drive changes to presentation formats.

When a single class is responsible to multiple actors, changes requested by one actor can inadvertently break functionality relied upon by another. This is the deep problem SRP addresses—not code organization for its own sake, but protecting each actor's concerns from interference by unrelated changes.

Understanding 'Responsibility'

The word 'responsibility' is perhaps the most overloaded term in software design. In the context of SRP, it has a specific meaning that differs from everyday usage.

Responsibility ≠ Task

A common mistake is equating 'responsibility' with 'task' or 'action.' Under this interpretation, a method that validates input and saves data would have two responsibilities. Taken to its extreme, this leads to classes with a single method each—a reductio ad absurdum that adds complexity without benefit.

Instead, think of responsibility as an axis of change—a dimension along which the class might evolve. A class that handles all aspects of user authentication (login, logout, session management, password reset) has a single responsibility: user authentication. All of these tasks change for the same reason (authentication requirements evolve) and are requested by the same actor (security team).

Responsibility = Cohesive Reason to Change

A responsibility represents a cohesive set of operations that:

Serve a common purpose
Change together when requirements evolve
Are requested by the same actor or stakeholder

This cohesion is the key. When operations are cohesive, bundling them together is not just acceptable—it's desirable. Separating cohesive operations into different classes creates artificial fragmentation that makes the code harder to understand and maintain.

Responsibility: What It Is and What It Isn't
Responsibility IS	Responsibility IS NOT
A cohesive axis of change	A single method or function
Aligned with stakeholder concerns	A purely technical classification
A reason the class might need modification	The number of things a class 'does'
Connected to an actor who requests changes	About code size or line count
A business or technical concern boundary	A measure of class complexity

The Cohesion Connection

SRP is deeply connected to the concept of cohesion from structured design. High cohesion means that the elements of a module (class) work together toward a single, well-defined purpose. Low cohesion means the elements serve disparate purposes that happen to share a physical location.

There are several types of cohesion, listed from weakest to strongest:

Coincidental cohesion (weakest): Elements are grouped arbitrarily. A Utilities class with unrelated helper functions.
Logical cohesion: Elements perform similar operations but on different data. A class that handles 'all printing' regardless of what is being printed.
Temporal cohesion: Elements are grouped because they happen at the same time. An Initializer class that sets up unrelated subsystems.
Procedural cohesion: Elements are grouped because they follow a sequence. A class that 'processes a transaction' by doing validation, calculation, and storage.
Communicational cohesion: Elements operate on the same data. A class that reads, transforms, and writes a specific record type.
Sequential cohesion: Output of one element becomes input of another. A data processing pipeline within a class.
Functional cohesion (strongest): All elements contribute to a single, well-defined task. A class that exclusively manages user sessions.

SRP pushes us toward functional cohesion—classes where every method, every field, every line of code contributes to a single, coherent purpose.

The Litmus Test

Ask yourself: 'If this class needs to change, who would request that change?' If the answer involves multiple distinct stakeholders—the sales team AND the operations team AND the compliance team—the class likely has multiple responsibilities. If all changes trace back to a single stakeholder or concern area, the class is probably cohesive.

Why 'One Reason to Change' Matters

Understanding the definition is only half the battle. To truly internalize SRP, we must understand why limiting classes to a single reason to change produces better software.

The Problem: Change Propagation

When a class has multiple responsibilities, it creates an invisible web of dependencies between those responsibilities. Consider a ReportGenerator class that:

Queries data from the database
Applies business rules to filter and sort data
Formats the output as PDF

Now imagine the DBA optimizes the database schema. Changes to responsibility #1 (data access) require modifying the ReportGenerator class. But this class is also used by the business logic (#2) and PDF generation (#3). Even though those responsibilities haven't changed, everyone who depends on ReportGenerator must:

Recompile against the modified class
Retest functionality that uses the class
Redeploy the class and its dependencies

This is change propagation—a phenomenon where localized changes ripple outward to affect unrelated code. SRP eliminates change propagation by ensuring that each class is affected only by changes to its single responsibility.

Consequences of Multiple Responsibilities

•Unexpected breakage: Changes to one feature break another because they share a class. The connection isn't visible in the code—it's implicit through the shared class boundary.
•Testing complexity: Testing one responsibility requires setting up mocks or stubs for all other responsibilities in the class, even when they're irrelevant to the test.
•Merge conflicts: Multiple developers working on different features modify the same class, creating merge conflicts that slow development and introduce bugs.
•Deployment risk: Deploying a change to one responsibility forces redeployment of all responsibilities, increasing the blast radius of any defects.
•Reasoning difficulty: Understanding what a class does requires understanding all its responsibilities simultaneously, increasing cognitive load exponentially.

The Solution: Separation of Concerns

SRP enforces separation of concerns at the class level. Each class becomes a self-contained unit that:

Encapsulates a single concern: All code related to that concern lives in one place.
Isolates from other concerns: Changes to other concerns cannot affect this class.
Presents a focused interface: The class's API clearly communicates its purpose.
Evolves independently: The class can be modified, tested, and deployed without affecting unrelated code.

This separation transforms large, entangled codebases into collections of focused, independently evolvable components. Each component can be understood in isolation, modified without fear, and reused in new contexts.

The Hidden Cost of Violations

SRP violations are insidious because they don't cause immediate failures. A class with three responsibilities works perfectly fine—until it doesn't. The pain comes months or years later when the codebase has grown and every change requires understanding the complex web of hidden dependencies created by shared classes. By then, fixing the problem requires risky, expensive refactoring.

A Concrete Example

Abstract principles become clear through concrete examples. Let's examine a class that violates SRP and explore how to recognize the violation.

The Problematic Class

Consider an Employee class in a payroll system:

Employee.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public class Employee {
    private String name;
    private String employeeId;
    private double hourlyRate;
    private List<TimeEntry> timeEntries;
    
    // Responsibility 1: Core employee data management
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmployeeId() { return employeeId; }
    
    // Responsibility 2: Pay calculation (business logic)
    public double calculatePay() {
        double totalHours = 0;
        for (TimeEntry entry : timeEntries) {
            totalHours += entry.getHours();
            if (entry.isOvertime()) {
                totalHours += entry.getOvertimeHours() * 0.5; // Time and a half
            }
        }
        return totalHours * hourlyRate;
    }
    
    // Responsibility 3: Persistence (database operations)
    public void save() {
        Connection conn = Database.getConnection();
        PreparedStatement stmt = conn.prepareStatement(
            "INSERT INTO employees (id, name, rate) VALUES (?, ?, ?)"
        );
        stmt.setString(1, employeeId);
        stmt.setString(2, name);
        stmt.setDouble(3, hourlyRate);
        stmt.executeUpdate();
    }
    
    // Responsibility 4: Reporting (presentation)
    public String generatePayStub() {
        StringBuilder sb = new StringBuilder();
        sb.append("=== PAY STUB ===
");
        sb.append("Employee: ").append(name).append("
");
        sb.append("ID: ").append(employeeId).append("
");
        sb.append("Pay: $").append(String.format("%.2f", calculatePay()));
        sb.append("
================");
        return sb.toString();
    }
}

Identifying the Violations

This class has four distinct responsibilities, each representing a different reason to change:

Responsibility	Actor	Example Change Request
Employee data	HR Department	Add new fields like department ID
Pay calculation	CFO/Accounting	Change overtime rules to 2x pay
Database operations	DBA/IT	Migrate from SQL to NoSQL
Pay stub format	Operations	Add tax withholding breakdown

Each of these actors might independently request changes. When the CFO changes overtime rules, developers must modify the same file that the DBA modifies for database changes. This creates:

Merge conflicts when changes happen simultaneously
Regression risk when unrelated code is deployed together
Testing burden when all code paths must be verified for any change
Cognitive overload when developers must understand unrelated concerns

The 'And' Test

When describing what a class does, if you find yourself using the word 'and' (especially more than once), you likely have an SRP violation. The Employee class above 'stores employee data AND calculates pay AND persists to database AND generates reports.' Each 'and' signals a potential separate responsibility.

The Refactored Design

Applying SRP means separating these responsibilities into distinct classes, each with a single reason to change:

The Data Class

First, we isolate the core employee data—the entity that represents an employee without behavior tied to specific use cases:

Employee.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
 * Pure data class representing an employee.
 * Reason to change: Employee data structure requirements.
 * Actor: HR Department
 */
public class Employee {
    private final String employeeId;
    private String name;
    private double hourlyRate;
    private List<TimeEntry> timeEntries;
    
    public Employee(String employeeId, String name, double hourlyRate) {
        this.employeeId = employeeId;
        this.name = name;
        this.hourlyRate = hourlyRate;
        this.timeEntries = new ArrayList<>();
    }
    
    // Getters and simple setters only
    public String getEmployeeId() { return employeeId; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public double getHourlyRate() { return hourlyRate; }
    public List<TimeEntry> getTimeEntries() { 
        return Collections.unmodifiableList(timeEntries); 
    }
    public void addTimeEntry(TimeEntry entry) { 
        timeEntries.add(entry); 
    }
}

The Pay Calculator

Next, we extract pay calculation into a focused class that encapsulates all business logic around compensation:

PayCalculator.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/**
 * Calculates employee pay based on time entries.
 * Reason to change: Pay calculation rules.
 * Actor: CFO/Accounting Department
 */
public class PayCalculator {
    private static final double OVERTIME_MULTIPLIER = 1.5;
    
    public double calculatePay(Employee employee) {
        double totalHours = 0;
        for (TimeEntry entry : employee.getTimeEntries()) {
            totalHours += entry.getHours();
            if (entry.isOvertime()) {
                totalHours += entry.getOvertimeHours() * (OVERTIME_MULTIPLIER - 1);
            }
        }
        return totalHours * employee.getHourlyRate();
    }
    
    public double calculateOvertimePay(Employee employee) {
        double overtimeHours = 0;
        for (TimeEntry entry : employee.getTimeEntries()) {
            if (entry.isOvertime()) {
                overtimeHours += entry.getOvertimeHours();
            }
        }
        return overtimeHours * employee.getHourlyRate() * OVERTIME_MULTIPLIER;
    }
}

The Repository

Persistence is isolated into a repository class:

EmployeeRepository.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
 * Handles employee persistence operations.
 * Reason to change: Database schema or persistence technology.
 * Actor: DBA/IT Infrastructure
 */
public class EmployeeRepository {
    private final DataSource dataSource;
    
    public EmployeeRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }
    
    public void save(Employee employee) {
        try (Connection conn = dataSource.getConnection()) {
            PreparedStatement stmt = conn.prepareStatement(
                "INSERT INTO employees (id, name, rate) VALUES (?, ?, ?)" +
                " ON CONFLICT (id) DO UPDATE SET name = ?, rate = ?"
            );
            stmt.setString(1, employee.getEmployeeId());
            stmt.setString(2, employee.getName());
            stmt.setDouble(3, employee.getHourlyRate());
            stmt.setString(4, employee.getName());
            stmt.setDouble(5, employee.getHourlyRate());
            stmt.executeUpdate();
        }
    }
    
    public Employee findById(String employeeId) {
        // ... database query implementation
    }
    
    public List<Employee> findAll() {
        // ... database query implementation
    }
}

The Pay Stub Generator

Finally, presentation logic is extracted into its own class:

PayStubGenerator.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/**
 * Generates pay stub reports in various formats.
 * Reason to change: Report format requirements.
 * Actor: Operations/Payroll Department
 */
public class PayStubGenerator {
    private final PayCalculator payCalculator;
    
    public PayStubGenerator(PayCalculator payCalculator) {
        this.payCalculator = payCalculator;
    }
    
    public String generateTextPayStub(Employee employee) {
        double pay = payCalculator.calculatePay(employee);
        StringBuilder sb = new StringBuilder();
        sb.append("=== PAY STUB ===
");
        sb.append("Employee: ").append(employee.getName()).append("
");
        sb.append("ID: ").append(employee.getEmployeeId()).append("
");
        sb.append("Pay: $").append(String.format("%.2f", pay));
        sb.append("
================");
        return sb.toString();
    }
    
    public PayStubPdf generatePdfPayStub(Employee employee) {
        // ... PDF generation logic
    }
}

The Result

Each class now has a single, clearly defined reason to change. Pay calculation rules change? Modify only PayCalculator. Database schema changes? Modify only EmployeeRepository. New report format needed? Modify only PayStubGenerator. The Employee data class changes only when the fundamental data model evolves. Each change is isolated, testable, and poses no risk to unrelated functionality.

Recognizing SRP Violations

Beyond the concrete example, you need heuristics for identifying SRP violations in any codebase. Here are the most reliable indicators:

Symptom 1: Large, Sprawling Classes

While class size alone doesn't determine SRP compliance, very large classes often contain multiple responsibilities. If a class has hundreds of methods or thousands of lines, it's almost certainly doing too much.

Symptom 2: Many Unrelated Imports/Dependencies

Examine the imports at the top of a class file. If you see a mix of database libraries, HTTP clients, file I/O utilities, and business domain types, the class is likely mixing responsibilities. A focused class imports libraries related to its single concern.

Symptom 3: Methods That Don't Use Most Class Fields

If a class has methods that only use a subset of its fields, those methods might belong in a different class. When methods form clusters that each use different fields, you're likely looking at multiple responsibilities bundled together.

Red Flags for SRP Violations

•The class name includes 'Manager', 'Handler', 'Processor', or 'Service' for multiple domains — UserAccountPaymentNotificationService is doing too much.
•You struggle to write a concise class description without using 'and' — A class that 'handles user authentication and logging and email notifications' has three responsibilities.
•Different team members frequently modify the same class for unrelated features — This indicates multiple actors with interests in the class.
•Testing requires mocking infrastructure unrelated to the behavior under test — Testing pay calculation shouldn't require a database mock.
•Changes to the class have unexpected side effects — Modifying report formatting breaks payment processing—a clear sign of entangled responsibilities.
•The class has multiple groups of related methods — If you can mentally partition the class into distinct 'areas', those areas might be separate responsibilities.

The Actor Analysis Technique

The most reliable way to identify SRP violations is to identify the actors—the stakeholders who might request changes:

List all the behaviors/capabilities of the class
For each behavior, ask: 'Who would request a change to this?'
Group behaviors by actor
If there are multiple distinct actor groups, you have multiple responsibilities

This technique directly applies Uncle Bob's refined definition and reveals hidden coupling between different stakeholder concerns.

The Granularity Question

A common question is 'How granular should responsibilities be?' The answer lies in actors, not arbitrary size limits. If all behaviors serve a single actor and change for connected reasons, they belong together regardless of how many methods are involved. If behaviors serve different actors, separate them regardless of how 'small' they seem. Let business boundaries, not code size, guide your decisions.

SRP Is Not About Single Methods

One of the most damaging misconceptions about SRP is that it mandates tiny classes with single methods. This interpretation leads to fragmented codebases where understanding any feature requires tracing through dozens of single-method classes connected by an explosion of interfaces.

The Over-Applied SRP Anti-Pattern

Consider a developer who interprets SRP too literally:

UserEmailValidator — validates only email format
UserPasswordValidator — validates only password strength
UserUsernameValidator — validates only username rules
UserValidator — orchestrates the three above
UserCreator — creates user records
UserPersister — saves user to database
UserEmailSender — sends welcome email
UserRegistrationOrchestrator — coordinates everything

This is not good design. It's fragmentation masquerading as SRP compliance.

All of these classes serve a single actor (the registration system) and change for a single reason (registration requirements evolve). Splitting them doesn't improve cohesion—it destroys it by scattering related logic across arbitrary boundaries.

The Cohesive Alternative

A better design keeps cohesive operations together:

UserRegistrationService.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
/**
 * Handles complete user registration workflow.
 * Reason to change: Registration requirements.
 * Actor: Registration/Onboarding Team
 */
public class UserRegistrationService {
    private final UserRepository userRepository;
    private final EmailService emailService;
    
    public UserRegistrationService(
            UserRepository userRepository,
            EmailService emailService) {
        this.userRepository = userRepository;
        this.emailService = emailService;
    }
    
    public RegistrationResult register(RegistrationRequest request) {
        // Validation is cohesive with registration
        ValidationResult validation = validateRequest(request);
        if (!validation.isValid()) {
            return RegistrationResult.failure(validation.getErrors());
        }
        
        // Creation is cohesive with registration
        User user = createUser(request);
        userRepository.save(user);
        
        // Welcome email is cohesive with registration
        emailService.sendWelcomeEmail(user);
        
        return RegistrationResult.success(user);
    }
    
    private ValidationResult validateRequest(RegistrationRequest request) {
        List<String> errors = new ArrayList<>();
        if (!isValidEmail(request.getEmail())) {
            errors.add("Invalid email format");
        }
        if (!isStrongPassword(request.getPassword())) {
            errors.add("Password does not meet strength requirements");
        }
        if (!isValidUsername(request.getUsername())) {
            errors.add("Username contains invalid characters");
        }
        return new ValidationResult(errors);
    }
    
    private boolean isValidEmail(String email) { /* ... */ }
    private boolean isStrongPassword(String password) { /* ... */ }
    private boolean isValidUsername(String username) { /* ... */ }
    
    private User createUser(RegistrationRequest request) {
        return new User(
            request.getUsername(),
            request.getEmail(),
            hashPassword(request.getPassword())
        );
    }
}

This class has many methods but a single responsibility: managing user registration. All methods support this responsibility and would change together if registration requirements evolved.

The Dependencies Are Key

Notice that the class depends on UserRepository and EmailService. These are injected dependencies that represent separate responsibilities:

UserRepository: Persistence responsibility (DBA actor)
EmailService: Email delivery responsibility (Infrastructure actor)

The UserRegistrationService doesn't implement these—it depends on abstractions for them. This is proper separation of concerns: each responsibility is isolated in its own class, while cohesive operations remain together.

Fragmentation Has Costs

Over-splitting creates its own problems: more files to navigate, more interfaces to understand, more wiring to configure, and more indirection to trace through when debugging. If splitting doesn't improve cohesion or test isolation, it's adding complexity without benefit. Always ask: 'Does this split serve a real architectural purpose, or am I just chasing small classes?'

Summary — The Definition Internalized

We've explored the Single Responsibility Principle in depth. Let's consolidate the key insights:

Key Takeaways

•The definition is precise: A class should have one, and only one, reason to change. This means one axis of change, not one method.
•Reasons to change come from actors: An actor is a person or group who might request changes. Classes should be responsible to a single actor.
•Responsibility means cohesion: A responsibility is a cohesive set of operations that change together and serve a common purpose.
•SRP prevents change propagation: When responsibilities are separated, changes to one cannot affect others.
•Look for multiple actors: If different stakeholders would request changes to different parts of a class, you have an SRP violation.
•Avoid over-fragmentation: SRP is about cohesion, not minimizing class size. Keep cohesive operations together.
•Use dependency injection for external concerns: Inject dependencies for responsibilities that belong to other actors.

What's Next

Now that we understand the basic definition—a class should have one reason to change—we need to explore the deeper formulation that Uncle Bob developed over years of teaching this principle. In the next page, we'll examine the actor-based formulation of SRP, which provides even more precise guidance for identifying and separating responsibilities. This refined definition connects SRP directly to organizational structure and stakeholder concerns, making it a powerful tool for architectural decision-making.

Page Complete

You now understand the Single Responsibility Principle at its definitional level: a class should have one reason to change, meaning it should serve a single actor and encapsulate a cohesive set of operations that evolve together. This understanding forms the foundation for applying SRP in real-world design decisions.