Refactoring for SRP - Learning Module

Loading content...

0/246

Splitting Responsibilities

The Art of Drawing the Line

You've identified that a class has too many responsibilities. You understand class extraction. But now comes the harder question: where exactly do you split?

A UserService class handles registration, authentication, profile management, preferences, and notification settings. There are clearly multiple responsibilities here—but should you have two classes, three, or five? Which methods go together? When does splitting become over-engineering?

Responsibility splitting is where SRP becomes an art as much as a science. It requires judgment, domain knowledge, and a clear understanding of the trade-offs involved. This page provides frameworks for making these decisions systematically rather than arbitrarily.

What You Will Learn

By the end of this page, you will understand multiple frameworks for deciding where to split responsibilities, how to handle ambiguous cases where reasonable engineers might disagree, when splitting adds value versus when it adds unnecessary complexity, and how to communicate and justify your splitting decisions to your team.

The Splitting Problem

Unlike extraction—where the question is "should this cluster become its own class?"—splitting addresses a higher-level challenge: given a class with N responsibilities, how should those N responsibilities be organized?

Consider a PaymentProcessor class with these capabilities:

Validate payment information
Calculate transaction fees
Apply discounts and promotions
Process credit card transactions
Process PayPal transactions
Process cryptocurrency transactions
Generate transaction receipts
Send confirmation emails
Log transactions for auditing
Handle failed payment retries

Each of these could be a separate class. But should it be? Do we want ten tiny classes, or can we find natural groupings that balance separation with practical usability?

The Over-Splitting Trap

Just as under-splitting (God classes) is problematic, over-splitting creates 'ravioli code'—many tiny classes that individually do little, require extensive coordination, and make it hard to understand the system as a whole. The goal is appropriate granularity, not maximum granularity.

The fundamental tension:

Too few classes → Each class does too much, SRP violations, hard to modify one concern without affecting others
Too many classes → Navigation overhead, excessive indirection, coordinating complexity, distributed logic

Finding the right balance requires a systematic approach, not gut feel. Let's establish frameworks for making these decisions.

Framework 1: Actor-Based Splitting

Robert C. Martin's (Uncle Bob) formulation of SRP focuses on actors—the people or systems that might request changes to the code. A responsibility is defined as "a reason to change," and reasons to change come from actors.

The Actor Test:

For each capability in your class, ask: "Who would request a change to this functionality?"

"The finance team wants to change how transaction fees are calculated"
"The marketing team wants to add a new promotion type"
"The security team wants to add fraud detection"
"The ops team wants to change the retry logic"
"The legal team wants to change receipt formats for compliance"

Different actors = different responsibilities = candidates for splitting.

Actor Analysis of PaymentProcessor
Capability	Primary Actor	Change Frequency	Responsibility Group
Validate payment information	Security/Compliance Team	Medium	Validation
Calculate transaction fees	Finance Team	High	Pricing
Apply discounts and promotions	Marketing Team	Very High	Pricing
Process credit card transactions	Payment Provider	Low	Processing
Process PayPal transactions	Payment Provider	Low	Processing
Process cryptocurrency transactions	Payment Provider	Medium	Processing
Generate transaction receipts	Legal/Compliance Team	Low	Reporting
Send confirmation emails	Marketing Team	Medium	Notification
Log transactions for auditing	Audit/Compliance Team	Low	Reporting
Handle failed payment retries	Ops Team	Medium	Resilience

Analysis reveals natural groupings:

PaymentValidator — Security/Compliance actor
PricingEngine — Finance and Marketing actors (closely related change patterns)
PaymentGateway — Payment provider actor (polymorphic implementations)
TransactionReporter — Legal/Audit actors
NotificationService — Marketing actor
RetryPolicy — Ops actor

This gives us 6 focused classes instead of 1 monolith or 10 micro-classes. The groupings make sense because they align with how the organization actually changes the system.

Actors May Overlap

When two capabilities have the same actor and change together (like fee calculation and discount application—both change when pricing strategy changes), they likely belong in the same class. SRP is about change reasons, not surface-level function groupings.

Framework 2: Volatility-Based Splitting

Another powerful framework examines rate of change. Code that changes frequently should be separated from code that rarely changes. This protects stable code from the risk introduced by frequent modifications.

The Volatility Principle:

Group together things that change at the same rate and for the same reasons. Separate things that have different change frequencies or different change drivers.

This principle helps prevent a common failure mode: stable, well-tested code being destabilized by changes to volatile, frequently-modified code that happens to live in the same class.

volatility_analysis.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Volatility Analysis of an E-commerce Order class
public class Order {
    // STABLE (changes rarely - core domain)
    private OrderId id;
    private List<LineItem> items;
    private Customer customer;
    private OrderStatus status;
    
    public Money calculateSubtotal() { /* Core calculation - stable */ }
    public void addItem(Product product, int quantity) { /* Core - stable */ }
    public void removeItem(LineItemId id) { /* Core - stable */ }
    
    // VOLATILE (changes frequently - business rules)
    public Money calculateDiscount() { /* Changes every sale season! */ }
    public Money calculateTax() { /* Changes with tax law updates */ }
    public boolean isEligibleForFreeShipping() { /* Changes with promotions */ }
    
    // VERY VOLATILE (changes constantly - presentation)
    public String formatForInvoice() { /* Changes with design updates */ }
    public String formatForEmail() { /* Changes with email templates */ }
    public Map<String, Object> toApiResponse() { /* Changes with API versions */ }
}

Splitting based on volatility:

The analysis reveals three volatility tiers:

Stable Core (changes rarely):
- Order class retains core domain logic
- LineItem, OrderStatus as value objects
- Changes only with fundamental business model shifts
Volatile Business Rules (changes frequently):
- DiscountCalculator — Changes with every promotion
- TaxCalculator — Changes with tax jurisdiction updates
- ShippingEligibility — Changes with logistics strategy
Very Volatile Presentation (changes constantly):
- OrderFormatter — Changes with UI/UX updates
- InvoiceRenderer — Changes with legal requirements
- EmailTemplateEngine — Changes with marketing campaigns

Volatility Anti-Pattern

•Stable and volatile code in same class
•Changes to promotions risk breaking core order logic
•Testing stable code requires setting up volatile dependencies
•Deployment of minor UI changes requires regression testing core logic

Volatility-Based Split

•Stable core isolated from volatile rules
•Changes to promotions localized to DiscountCalculator
•Core order logic tested independently
•UI changes only affect presentation layer classes

Mining Git History

Your version control history is a goldmine for volatility analysis. Commands like 'git log --oneline --all [file]' or tools that visualize code churn reveal which parts of your codebase change frequently. Let data drive your splitting decisions.

Framework 3: Domain-Driven Splitting

Domain-Driven Design (DDD) provides another lens for responsibility splitting. It emphasizes that software structure should reflect the business domain, and that "bounded contexts" define natural responsibility boundaries.

The Domain Alignment Principle:

Split responsibilities along the same lines that domain experts split their mental models. If business stakeholders describe things separately, those things should likely be separate classes.

Example: An "Account" That's Really Three Things

Consider a banking application with an Account class. In conversations with domain experts, you notice they discuss three different concepts:

The Account as Identity — Account number, owner, opening date, status
The Account as Balance Holder — Current balance, available balance, holds
The Account as Transaction History — List of transactions, statement generation

These aren't three aspects of one thing—they're three genuinely different concepts that happen to share an identifier. Splitting along these domain lines creates classes that match how the business thinks:

domain_driven_split.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
// Domain-driven split of a Banking Account
 
// Identity context: Who owns what
public class AccountIdentity {
    private final AccountNumber number;
    private final CustomerId owner;
    private final LocalDate openedDate;
    private AccountStatus status;
    
    public boolean isActive() { return status == AccountStatus.ACTIVE; }
    public boolean belongsTo(CustomerId customer) { return owner.equals(customer); }
}
 
// Balance context: What's available
public class AccountBalance {
    private final AccountNumber accountId;
    private Money currentBalance;
    private Money availableBalance;
    private List<Hold> holds;
    
    public Money getSpendableAmount() { 
        return availableBalance.subtract(sumHolds()); 
    }
    public void applyHold(Hold hold) { holds.add(hold); }
    public void credit(Money amount) { 
        currentBalance = currentBalance.add(amount);
        recalculateAvailable();
    }
}
 
// History context: What happened
public class TransactionHistory {
    private final AccountNumber accountId;
    private final TransactionRepository repository;
    
    public List<Transaction> getTransactions(DateRange range) {
        return repository.findByAccountAndDateRange(accountId, range);
    }
    public Statement generateStatement(Month month) {
        return new Statement(getTransactions(month.toDateRange()));
    }
}

The Ubiquitous Language Test:

Do domain experts use different words or phrases for different aspects of a concept? If they say:

"Check if the account is active" (identity)
"What's the balance on that account?" (balance)
"Pull up the transaction history" (history)

...they're unconsciously revealing domain boundaries. Align your code with their language.

Event Storming for Discovery

Event Storming and other collaborative modeling techniques help surface domain boundaries. When domain experts naturally cluster events and commands differently, those clusters suggest responsibility splits. The structure comes from the domain, not arbitrary technical decisions.

Handling Ambiguous Cases

Real-world code rarely offers clean splitting lines. Often, functionality seems to partially belong in multiple places, or frameworks conflict in their recommendations. Here's how to navigate ambiguity.

When Actor-Based and Volatility-Based Disagree:

Sometimes the same team requests changes (single actor), but some of their requests are frequent while others are rare. In such cases:

Check if the "single actor" is actually multiple roles wearing one hat
Prioritize volatility for technical separation
Consider namespace/package organization to maintain conceptual grouping while achieving physical separation

ambiguity_resolution.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
// Situation: Marketing team owns both email templates (volatile) 
// and customer segmentation rules (stable)
 
// Option 1: Single class (Actor-based says same team)
public class MarketingEngine {
    public void sendCampaignEmail(Campaign c) { /* Volatile */ }
    public Segment classifyCustomer(Customer c) { /* Stable */ }
}
 
// Option 2: Split by volatility, organize by actor
package marketing.campaigns;  // Volatile
public class CampaignEngine {
    public void sendCampaignEmail(Campaign c) { }
}
 
package marketing.segmentation;  // Stable
public class SegmentationEngine {
    public Segment classifyCustomer(Customer c) { }
}
 
// The marketing package groups them conceptually
// The subpackages separate them physically
// Marketing team still "owns" both, but volatility is managed

When Functionality Spans Boundaries:

Some operations genuinely span multiple responsibilities. A transfer() operation involves source account, destination account, transaction logging, and notification. No single class "owns" it.

Solution: The Coordinator Pattern

Create a dedicated coordinator (or "use case" or "application service") that orchestrates the cross-cutting operation without containing domain logic:

coordinator_pattern.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
// Coordinator for cross-cutting transfer operation
public class TransferCoordinator {
    private final AccountBalance sourceBalance;
    private final AccountBalance destBalance;
    private final TransactionLogger logger;
    private final NotificationService notifier;
    
    public TransferResult execute(TransferRequest request) {
        // Validate preconditions
        if (!sourceBalance.canWithdraw(request.amount())) {
            return TransferResult.insufficientFunds();
        }
        
        // Orchestrate the operation
        sourceBalance.debit(request.amount());
        destBalance.credit(request.amount());
        
        Transaction tx = logger.log(request);
        notifier.sendTransferConfirmation(request);
        
        return TransferResult.success(tx);
    }
}
 
// The coordinator doesn't own business rules
// Each collaborator handles its own responsibility
// Testing is straightforward with mock collaborators

Feature Envy is a Clue

If your coordinator is reaching into collaborators' internals (accessing their fields, calling many private-ish methods), it may be that the 'coordination' actually belongs in one of the domain classes. Coordinators should delegate, not micromanage.

Finding the Goldilocks Zone

The ideal level of splitting isn't about following rules mechanically—it's about finding the "Goldilocks zone" where classes are neither too big nor too small. Here are heuristics for recognizing when you've found it.

Signs of Right-Sized Classes
Category	Under-Split (Too Big)	Over-Split (Too Small)	Right-Sized
Naming	Class name is vague or compound ('UserServiceManager')	Class name is awkward or forced ('UserNameValidator')	Class name is a single, clear noun
Description	Requires 'and' to describe ('handles auth and profiles and prefs')	Description is trivially obvious from name	One sentence, no 'and', adds insight
Methods	Methods cluster into groups that don't interact	Class has only 1-2 methods	5-15 methods that collaborate
Fields	Many fields unused by most methods	No fields or only injected deps	Most methods use most fields
Testing	Tests require complex setup with many irrelevant parts	Tests are trivial, almost redundant	Tests are focused but meaningful
Changes	Changes often affect unrelated methods	Simple changes require multiple class updates	Changes are localized to one class

Quantitative Guidelines (Rough):

While not hard rules, these ranges indicate healthy class sizes:

Lines of code: 50-300 lines is typical; <30 often too small, >500 often too big
Methods: 5-15 is healthy; <3 is often trivial, >20 suggests splitting
Fields: 3-8 is typical; 0 fields suggests it might be a function, not a class
Dependencies: 3-7 injected dependencies is manageable; >10 is a warning sign
Cyclomatic complexity of any method: <10 is manageable; >20 needs refactoring

The Rule of Explaining

Imagine explaining your class to a new team member. If you can explain its purpose in 20-30 seconds without hand-waving, it's probably right-sized. If you need 5 minutes or say 'it handles a bunch of stuff,' it's too big. If explaining seems pointless because it's obvious, it might be too small.

Splitting Anti-Patterns to Avoid

Understanding what not to do is as valuable as knowing the right approach. These anti-patterns create the illusion of SRP compliance while actually making code worse.

Anti-Pattern: Splitting by Technical Layer

Splitting a class into UserValidator, UserProcessor, UserPersister because you read about layers somewhere. This often scatters a single responsibility across multiple classes.

The Problem:

A simple change to "how users work" requires modifying three classes
The classes have intimate knowledge of each other
No single class can be understood alone
You've increased coupling while pretending to increase cohesion

layer_splitting_antipattern.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ANTI-PATTERN: Technical layer splitting
public class UserValidator {
    public ValidationResult validate(UserDto dto) { /* ... */ }
}
 
public class UserProcessor {
    public User process(UserDto dto, ValidationResult result) { /* ... */ }
}
 
public class UserPersister {
    public void persist(User user) { /* ... */ }
}
 
// All three are tightly coupled and change together
// A new field requires changes to ALL THREE classes
// This isn't SRP - it's one responsibility scattered across three files
 
// BETTER: Single UserService or domain-based split
public class UserRegistration {
    // Validates, processes, and persists - one responsibility: registering users
    public User register(RegistrationRequest request) { /* ... */ }
}

Summary: The Art of Responsibility Splitting

Splitting responsibilities is where engineering judgment meets SRP theory. There's no formula that produces the "right" split—but there are frameworks that guide us toward good decisions.

Key Takeaways

•Use multiple frameworks — Actor-based, volatility-based, and domain-driven splitting each reveal different insights. Apply all three.
•Recognize that frameworks may conflict — When they do, prioritize based on your context: volatility for technical stability, domain alignment for business clarity.
•Create coordinators for cross-cutting operations — When operations span responsibilities, use dedicated orchestrators rather than compromising class boundaries.
•Find the Goldilocks zone — Classes should be neither God classes nor trivial wrappers. Use quantitative and qualitative heuristics to find the right size.
•Avoid splitting anti-patterns — Technical-layer splitting, one-method-per-class, and anemic domains create the illusion of SRP without its benefits.
•Let the domain guide you — When in doubt, align with how domain experts think and speak about the system. That alignment pays dividends in maintainability.

What's next:

Once you've split responsibilities, a new challenge emerges: maintaining cohesion after the split. The next page explores how to ensure that extracted and split classes remain internally cohesive, and how to recognize when a split has gone wrong and needs adjustment.

Page Complete

You now have multiple frameworks for deciding where to split responsibilities, along with guidance on handling ambiguous cases and avoiding common anti-patterns. Apply these systematically rather than relying on intuition alone.