SRP for Classes — The Foundation of Responsibility - Srp At Different Levels | OneNoughtOne

0/246

System Design LLDSRP at Different Levels

SRP at Different Levels

LevelIntermediate

Duration75 mins

TopicSRP at Different Levels

1 / 4

SRP for Classes — The Foundation of Responsibility

The Class That Did Everything

Every seasoned engineer has encountered it—the God Class. Perhaps it was called UserManager, ApplicationController, or simply Utils. It started as a reasonable 200-line class, but over years of feature additions, bug fixes, and 'just one more method,' it swelled into a 3,000-line monstrosity that half the team feared and the other half refused to touch.

This class became the bottleneck for everything. Every feature touched it. Every merge conflict involved it. Every regression traced back to it. The class that did everything became the class that broke everything.

The Single Responsibility Principle (SRP), when properly applied at the class level, is your primary weapon against this chaos. It transforms unwieldy code into focused, manageable components that evolve gracefully over time.

What You Will Master

By the end of this page, you will understand how to identify a class's responsibility, recognize when a class has acquired multiple responsibilities, and refactor toward focused classes that are easier to maintain, test, and extend. You'll develop the intuition to design classes correctly from the start.

Defining Class-Level Responsibility

At the class level, SRP can be stated as:

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

But what exactly constitutes a 'reason to change'? Uncle Bob Martin, who popularized SRP, refined this definition over time to be more precise:

A class should have only one actor (stakeholder or source of change) that it serves.

This actor-based definition is crucial because 'responsibility' is fundamentally about who drives changes to the code, not just what the code does. Different actors have different concerns, different timelines, and different reasons for requesting modifications.

The Actor Test

When evaluating whether a class follows SRP, ask: 'Who would request changes to this class?' If the answer involves multiple distinct stakeholders—the CFO for reporting logic, the CTO for technical requirements, the compliance team for legal rules—you likely have an SRP violation.

Understanding 'Actor' in Practice:

An 'actor' is not necessarily a specific person, but rather a role or group that has authority over certain requirements. Common actors include:

Business stakeholders who define domain logic and business rules
Operations teams who care about logging, monitoring, and deployment
Security teams who specify authentication and authorization rules
UX designers who determine presentation and formatting
Database administrators who govern data access patterns

When a single class serves multiple actors, changes requested by one actor can inadvertently break functionality owned by another. This coupling creates fragility and reduces team autonomy.

ViolatingActorSeparation.java
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
// SRP VIOLATION: Multiple actors influence this class
public class Employee {
    private String name;
    private double hourlyRate;
    private int hoursWorked;
    
    // Method for HR Department (Actor 1)
    public double calculatePay() {
        return hourlyRate * hoursWorked;
    }
    
    // Method for Accounting Department (Actor 2)  
    public String generatePayrollReport() {
        return String.format("Employee: %s, Pay: $%.2f", 
            name, calculatePay());
    }
    
    // Method for IT/Persistence (Actor 3)
    public void saveToDatabase(Connection conn) {
        // SQL operations to persist employee
    }
    
    // Problem: Change to calculatePay() for HR
    // might break report format for Accounting
    // Database schema changes affect domain logic
}

In the example above, three distinct actors influence the Employee class:

HR owns the pay calculation logic
Accounting owns the report format
IT/DBA owns the persistence mechanism

When the CFO requests a change to how overtime is calculated, the developer must modify calculatePay(). But this method is also used by generatePayrollReport(). A subtle change in pay calculation could alter report output, potentially breaking downstream accounting processes that depend on specific formatting.

This is the essence of SRP violation—hidden coupling between unrelated concerns.

Cohesion — The Measure of Responsibility

Cohesion is the degree to which the elements within a module (in this case, a class) belong together. A highly cohesive class has methods and data that are closely related, all working toward a single, well-defined purpose. A low-cohesion class is a grab-bag of loosely related or unrelated functionality.

Cohesion and SRP are deeply intertwined:

A class with a single responsibility naturally exhibits high cohesion.

Conversely, when you observe low cohesion—methods that don't use most of the class's fields, or fields that are only used by a subset of methods—you're often looking at an SRP violation waiting to be extracted.

Cohesion Types Ranked by Strength
Cohesion Type	Description	SRP Alignment
Functional	All parts contribute to a single, well-defined task	Strong — Ideal for SRP
Sequential	Output of one part is input to another	Good — Often appropriate
Communicational	Methods operate on the same data	Moderate — Watch for splits
Procedural	Parts always execute in a certain order	Weak — Consider separation
Temporal	Parts are grouped by when they execute	Poor — Usually violates SRP
Logical	Parts are logically categorized together	Poor — 'Utility' class smell
Coincidental	Parts have no meaningful relationship	Worst — Definite violation

Measuring Cohesion:

While formal metrics like LCOM (Lack of Cohesion of Methods) exist, practical cohesion assessment often relies on heuristics:

The Field-Method Matrix Test: Create a mental matrix where rows are methods and columns are instance fields. Mark which methods access which fields. In a highly cohesive class, most methods access most fields. If you see clear clusters—some methods only touch certain fields while others touch different fields—you likely have two responsibilities waiting to be separated.

CohesionAnalysis.java
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
// LOW COHESION: Methods cluster around different fields
public class UserService {
    // Cluster A: Authentication fields
    private PasswordEncoder encoder;
    private SessionManager sessions;
    
    // Cluster B: Profile fields  
    private ProfileRepository profiles;
    private ImageResizer imageResizer;
    
    // Only uses Cluster A
    public boolean authenticate(String user, String pass) {
        // Uses encoder and sessions, never touches profiles or images
    }
    
    // Only uses Cluster A
    public void logout(String sessionId) {
        sessions.invalidate(sessionId);
    }
    
    // Only uses Cluster B
    public void updateAvatar(String userId, byte[] image) {
        // Uses profiles and imageResizer, never touches auth
    }
    
    // Only uses Cluster B
    public Profile getProfile(String userId) {
        return profiles.findById(userId);
    }
    
    // INSIGHT: Two classes hiding inside one
    // AuthenticationService + ProfileService
}

The Cohesion Smell

If you find yourself prefixing method names to create logical groupings within a class (authLogin, authLogout, profileUpdate, profileGet), you're documenting an SRP violation. Those prefixes are the names of the classes that should exist.

Recognizing SRP Violations in Classes

SRP violations rarely announce themselves. They accumulate gradually as features are added, and by the time they're obvious, significant refactoring is required. Learning to recognize early warning signs is essential for maintaining healthy codebases.

Warning Signs of SRP Violations

•Multiple 'and's in the class description — 'This class handles user authentication AND manages user profiles AND sends notification emails.' Each 'and' might be a separate responsibility.
•High fan-out (many dependencies) — A class that imports 15+ other classes is likely doing too much. Each dependency often represents a different concern.
•Large class size — While line count alone isn't definitive, classes exceeding 300-500 lines deserve scrutiny. Size correlates with responsibility accumulation.
•Frequent modification — If every feature touches the same class, that class has become a coupling point for unrelated concerns.
•Difficult naming — Struggling to name a class without generic terms (Manager, Handler, Processor, Service with no qualifier) often indicates unclear responsibility.
•Test complexity explosion — When unit testing a class requires extensive mocking of unrelated dependencies, SRP is likely violated.
•God classes — Classes that 'know too much' about the system, often serving as central hubs for information and behavior that should be distributed.

The Modification History Test:

Examine your version control history. For a given class, look at the last 10 commits that modified it:

Do the commits relate to a single theme, or scattered concerns?
Were the modifications made by the same team, or multiple teams?
Did changes cluster in certain methods while leaving others untouched?

If you see patterns like 'fix payment calculation,' 'update email template,' 'add audit logging,' and 'change database timeout' all affecting the same class, you're looking at an SRP violation manifested through history.

GodClassExample.java
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
// THE GOD CLASS: Maximum SRP violation
public class OrderProcessor {
    // Dependencies reveal scattered responsibilities
    private DatabaseConnection db;
    private EmailService email;
    private PaymentGateway payments;
    private InventoryService inventory;
    private ShippingCalculator shipping;
    private TaxCalculator tax;
    private FraudDetector fraud;
    private AuditLogger audit;
    private NotificationHub notifications;
    private ReportGenerator reports;
    
    public Order processOrder(Cart cart, Customer customer) {
        // Responsibility 1: Validation
        validateCart(cart);
        
        // Responsibility 2: Fraud detection
        if (fraud.isSuspicious(customer, cart)) {
            flagForReview(cart);
            return null;
        }
        
        // Responsibility 3: Pricing/Tax calculation
        double subtotal = calculateSubtotal(cart);
        double taxAmount = tax.calculate(subtotal, customer.getAddress());
        double shippingCost = shipping.calculate(cart, customer.getAddress());
        
        // Responsibility 4: Payment processing
        PaymentResult result = payments.charge(customer, subtotal + taxAmount + shippingCost);
        
        // Responsibility 5: Inventory management
        inventory.reserve(cart.getItems());
        
        // Responsibility 6: Order persistence
        Order order = createOrder(cart, customer, result);
        db.save(order);
        
        // Responsibility 7: Notifications
        email.sendConfirmation(customer, order);
        notifications.push(customer.getId(), "Order confirmed!");
        
        // Responsibility 8: Audit
        audit.log("ORDER_CREATED", order.getId());
        
        // Responsibility 9: Analytics/Reporting
        reports.recordSale(order);
        
        return order;
    }
    
    // 50+ more methods mixing all these concerns...
}

The Hidden Cost

This class is a nexus of coupling. Any change to payment processing, email formatting, tax rules, fraud detection, or a dozen other concerns forces modification to this single file. Multiple developers working on unrelated features will constantly conflict in version control. Testing requires mocking 10 dependencies. This is the class everyone dreads.

Refactoring Toward Single Responsibility

Transforming an SRP-violating class into properly focused components is a surgical process. The goal is to identify responsibility boundaries and extract cohesive units while maintaining existing behavior. Here's a systematic approach:

SRP Refactoring Process

•Identify Responsibilities — List all the distinct things the class does. Group related functionality together.
•Map to Actors — For each responsibility group, identify which stakeholder owns it.
•Extract Data First — If certain fields only serve certain responsibilities, consider extracting data classes.
•Extract Collaborators — Create new classes for each responsibility and inject them as dependencies.
•Facade the Transition — Initially, the original class can delegate to new classes, maintaining the existing API.
•Update Callers Gradually — Migrate clients to use the new, focused classes directly.
•Remove the Facade — Once all clients are migrated, the original class can be simplified or removed.

Applying the Process:

Let's refactor the Employee class we saw earlier. We identified three actors: HR (pay calculation), Accounting (reporting), and IT (persistence).

RefactoredEmployee.java
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
60
61
62
63
64
65
66
67
68
69
// STEP 1: Core domain class - only holds data and core identity
public class Employee {
    private final String id;
    private String name;
    private double hourlyRate;
    private int hoursWorked;
    
    // Simple getters and setters - domain data only
    public String getId() { return id; }
    public String getName() { return name; }
    public double getHourlyRate() { return hourlyRate; }
    public int getHoursWorked() { return hoursWorked; }
    
    // Note: No calculation, no persistence, no formatting
}
 
// STEP 2: Pay Calculator - serves HR actor
public class PayCalculator {
    public double calculateRegularPay(Employee employee) {
        return employee.getHourlyRate() * employee.getHoursWorked();
    }
    
    public double calculateOvertime(Employee employee, int regularHours) {
        int overtimeHours = Math.max(0, employee.getHoursWorked() - regularHours);
        return overtimeHours * employee.getHourlyRate() * 1.5;
    }
    
    public double calculateTotalPay(Employee employee) {
        return calculateRegularPay(employee) + calculateOvertime(employee, 40);
    }
}
 
// STEP 3: Report Generator - serves Accounting actor
public class PayrollReportGenerator {
    private final PayCalculator payCalculator;
    
    public PayrollReportGenerator(PayCalculator payCalculator) {
        this.payCalculator = payCalculator;
    }
    
    public String generatePayrollReport(Employee employee) {
        double pay = payCalculator.calculateTotalPay(employee);
        return String.format("Employee: %s
ID: %s
Total Pay: $%.2f",
            employee.getName(), employee.getId(), pay);
    }
    
    public String generateDepartmentSummary(List<Employee> employees) {
        // Accounting-specific report formatting
    }
}
 
// STEP 4: Repository - serves IT/DBA actor
public class EmployeeRepository {
    private final DataSource dataSource;
    
    public void save(Employee employee) {
        // Pure persistence logic - isolated from domain
    }
    
    public Employee findById(String id) {
        // Pure persistence logic
    }
    
    public List<Employee> findByDepartment(String department) {
        // Query logic isolated from business rules
    }
}

Benefits Realized

Each class now has a single reason to change. HR can modify pay calculations without affecting reports. Accounting can change report formats without risking pay logic. DBAs can optimize queries without touching business rules. Teams can work independently, and testing becomes trivial—no complex mocking required.

The Balance — Avoiding Over-Separation

While SRP violations cause significant problems, the opposite extreme—excessive decomposition—creates its own challenges. Taken to an absurd degree, SRP could justify a separate class for every method, leading to an explosion of tiny classes that are individually simple but collectively incomprehensible.

Signs of Over-Separation

•Shotgun surgery — Adding a simple feature requires modifying 10+ files
•Dependency chains — Class A depends on B depends on C depends on D... just to perform basic operations
•Navigation overhead — Understanding a simple flow requires jumping between many files
•Connector classes — Many classes exist only to wire other classes together
•Lost context — The meaning of operations becomes obscured across too many abstractions

Finding the Right Granularity:

The appropriate level of decomposition depends on several factors:

Rate of change: If two pieces of functionality always change together and are owned by the same actor, keeping them together avoids unnecessary indirection.

Cognitive load: A class should be comprehensible as a unit. If reading a class requires simultaneously holding 5 other classes in mind, you've gone too far.

Team structure: Conway's Law applies—system structure mirrors organizational structure. If one team owns both payment and refund logic, a single PaymentService might be appropriate. If separate teams own each, separate classes make sense.

Reuse potential: Functionality likely to be reused across different contexts benefits from extraction. Functionality that only exists in one context may not.

Over-Separated

•EmailValidator
•EmailFormatter
•EmailAddressParser
•EmailDomainChecker
•EmailLocalPartValidator
•5 classes for email handling

Appropriately Cohesive

•EmailAddress (value object)
•Encapsulates all email logic
•Validates on construction
•Exposes localPart() and domain()
•Single cohesive concept
•1 class that's easy to use

The Litmus Test

Ask yourself: 'Would these ever change independently?' and 'Does separating these help or hurt understanding?' If two pieces always change together and combining them aids comprehension, keep them together. SRP is about managing change, not minimizing class size.

SRP and Testing

One of the most practical benefits of SRP-compliant classes is dramatically improved testability. The relationship is almost definitional: a class with a single responsibility is easy to test because it has a single thing to verify.

The testing benefits compound:

SRP Testing Advantages

•Minimal dependencies — Focused classes have fewer collaborators, requiring less mocking
•Clear assertions — Single responsibility means clear expected outcomes
•Isolated failures — When tests fail, the cause is localized to the class's one concern
•Fast tests — Fewer dependencies mean faster test execution
•Higher coverage — Smaller, focused classes are easier to cover completely
•Meaningful tests — Tests document actual behavior, not incidental coupling

TestingComparison.java
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
// TESTING SRP-VIOLATING CLASS: Complex, fragile tests
class OrderProcessorTest {
    @Mock DatabaseConnection db;
    @Mock EmailService email;
    @Mock PaymentGateway payments;
    @Mock InventoryService inventory;
    @Mock ShippingCalculator shipping;
    @Mock TaxCalculator tax;
    @Mock FraudDetector fraud;
    @Mock AuditLogger audit;
    @Mock NotificationHub notifications;
    @Mock ReportGenerator reports;
    
    @Test
    void processOrder_happyPath() {
        // 30 lines of mock setup...
        when(fraud.isSuspicious(any(), any())).thenReturn(false);
        when(payments.charge(any(), anyDouble())).thenReturn(success);
        when(shipping.calculate(any(), any())).thenReturn(10.0);
        when(tax.calculate(anyDouble(), any())).thenReturn(5.0);
        // ... more mocking ...
        
        Order result = processor.processOrder(cart, customer);
        
        // What are we even testing? All 9 responsibilities?
        // If this fails, which responsibility broke?
    }
}
 
// TESTING SRP-COMPLIANT CLASS: Simple, focused tests
class PayCalculatorTest {
    private PayCalculator calculator = new PayCalculator();
    
    @Test
    void calculateTotalPay_withOvertime_appliesMultiplier() {
        Employee employee = new Employee("1", "Jane", 20.0, 50);
        
        double pay = calculator.calculateTotalPay(employee);
        
        // 40 regular hours × $20 = $800
        // 10 overtime hours × $20 × 1.5 = $300
        // Total = $1100
        assertEquals(1100.0, pay);
    }
    
    @Test
    void calculateTotalPay_noOvertime_regularRateOnly() {
        Employee employee = new Employee("2", "John", 25.0, 35);
        
        double pay = calculator.calculateTotalPay(employee);
        
        assertEquals(875.0, pay); // 35 × $25
    }
    
    // Tests are clear, fast, and test exactly one thing
}

The Mocking Smell

If your test setup requires mocking more than 2-3 dependencies, step back and ask whether the class under test violates SRP. Excessive mocking is a symptom, not a normal cost of testing. Well-designed classes rarely need complex mock orchestration.

Real-World Examples

Let's examine SRP application in common scenarios from production systems.

Before: Typical UserService violation

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class UserService {
    // Responsibility 1: User CRUD
    public User createUser(CreateUserRequest req) { ... }
    public User getUser(String id) { ... }
    public void updateUser(String id, UpdateRequest req) { ... }
    
    // Responsibility 2: Authentication
    public AuthToken login(String username, String password) { ... }
    public void logout(String token) { ... }
    public boolean validateToken(String token) { ... }
    
    // Responsibility 3: Password management
    public void changePassword(String userId, String old, String new) { ... }
    public void resetPassword(String email) { ... }
    
    // Responsibility 4: Profile management
    public void updateAvatar(String userId, byte[] image) { ... }
    public void updatePreferences(String userId, Preferences prefs) { ... }
}

After: SRP-compliant separation

Java
1
2
3
4
5
// Each class has ONE actor
public class UserRepository { ... }        // IT/DBA: CRUD operations
public class AuthenticationService { ... } // Security: Login/logout
public class PasswordService { ... }       // Security: Password policies
public class ProfileService { ... }        // Product/UX: Profile features

Summary: SRP for Classes

Class-level SRP is the foundation upon which all other applications of the principle rest. Master it here, and the extension to methods, modules, and architecture becomes natural.

Key Takeaways

•SRP is about actors, not actions — A class should serve one stakeholder, not perform one action.
•Cohesion is the measure — High cohesion naturally results from single responsibility; low cohesion signals violation.
•Watch for warning signs — Multiple 'and's in descriptions, high dependency counts, and large class sizes indicate problems.
•Extract by responsibility — Refactor by identifying responsibility clusters and extracting them into focused classes.
•Balance is essential — Over-separation creates its own problems; find the right granularity for your context.
•Testing validates design — If a class is hard to test, SRP is probably violated. Simple tests indicate good design.

What's Next:

The class level is just the beginning. In the next page, we'll zoom in even further to examine SRP at the method level—how individual functions and methods should also embody single responsibility, and how this microscopic application of the principle affects code readability, reusability, and testability.

Page Complete

You now understand how SRP applies at the class level—the most common and foundational application of the principle. You can identify violations, understand their costs, apply systematic refactoring, and balance separation against over-engineering. Next, we'll explore SRP at the method level.