System Design (LLD)Refactoring for SRP

Refactoring for Single Responsibility Principle

LevelIntermediate

Duration90 mins

TopicRefactoring for SRP

1 / 4

Extracting Classes

The Art of Surgical Class Extraction

Every experienced software engineer has encountered the moment when they realize a class has grown beyond its original purpose. A UserService that started as a simple authentication handler now manages user preferences, sends emails, generates reports, and coordinates with three external APIs. The class has become a tangled web of unrelated responsibilities—a God Class that knows too much and does too much.

The solution isn't to rewrite everything from scratch. Instead, the disciplined approach is class extraction—the systematic process of identifying cohesive groups of functionality within a bloated class and surgically relocating them to new, focused classes.

Class extraction is the most fundamental and frequently applied technique for achieving SRP compliance. When executed correctly, it transforms monolithic monstrosities into elegant, maintainable designs. When executed poorly, it creates a different kind of mess—fragmented code scattered across too many trivial classes with excessive coupling.

What You Will Learn

By the end of this page, you will master the complete process of class extraction: recognizing extraction candidates through multiple diagnostic techniques, executing extractions that preserve behavior, establishing appropriate relationships between original and extracted classes, and validating that the resulting design genuinely improves upon the original.

Understanding Class Extraction

Class extraction is the refactoring technique of moving a coherent subset of a class's fields and methods into a newly created class, then establishing an appropriate relationship (typically composition) between the original class and the extracted class.

This technique directly addresses SRP violations by separating concerns that have inadvertently merged within a single class. The goal is to create classes where each has "one, and only one, reason to change."

The fundamental principle:

A class that contains multiple clusters of highly related methods and fields—where each cluster is relatively independent of the others—is a prime candidate for extraction. Each cluster represents a distinct responsibility that deserves its own class.

The Cohesion Test

Ask yourself: 'If I removed this group of methods and fields, would the remaining class still make sense as a coherent concept?' If yes, you've likely identified an extraction candidate. If the remaining class would be meaningless or incomplete, the functionality is intrinsically part of that class's core responsibility.

When to extract vs. when to leave alone:

Class extraction is not always the right answer. It's appropriate when:

Distinct responsibilities have merged — The class handles multiple unrelated concerns that change for different reasons
Cohesive clusters exist — Groups of methods operate primarily on subsets of the class's fields
Reuse is blocked — Part of the class's functionality could be reused, but the entire class must be included
Testing is complicated — Testing one aspect requires setting up unrelated parts of the class
The class is growing uncontrollably — Each feature request adds more code to an already large class

Extraction is not appropriate when:

All methods truly collaborate — Every method uses most of the class's state
Extraction would create trivial classes — The "extracted" class would have one method and one field
Coupling would increase — The extracted class would need extensive access to the original's internals
The abstraction is forced — No natural name exists for the extracted responsibility

Identifying Extraction Candidates

The first and most critical step in class extraction is correctly identifying what should be extracted. This requires a combination of analytical techniques that examine the class from multiple perspectives.

Technique 1: Field Affinity Analysis

Group methods by which fields they access. Create a matrix where rows are methods and columns are fields, marking which methods use which fields. Clusters in this matrix reveal potential extraction targets.

Methods that access the same subset of fields likely represent a single responsibility. If methods A, B, and C all work with fields X and Y, while methods D, E, and F work with fields Z and W, you have two distinct responsibilities.

field_affinity_example.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
// Before extraction: A class with two distinct field clusters
public class OrderProcessor {
    // Cluster 1: Order validation fields
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    // Cluster 2: Shipping calculation fields
    private ShippingZone zone;
    private double weight;
    private Map<String, Double> rateTable;
    
    // Cluster 1 methods: Only use validation fields
    public boolean validate(Order order) {
        validationErrors.clear();
        for (Rule rule : rules.getRules()) {
            if (!rule.check(order)) {
                validationErrors.add(rule.getMessage());
            }
        }
        isValidated = validationErrors.isEmpty();
        return isValidated;
    }
    
    public List<String> getValidationErrors() {
        return new ArrayList<>(validationErrors);
    }
    
    // Cluster 2 methods: Only use shipping fields
    public double calculateShipping(Order order) {
        weight = order.getTotalWeight();
        zone = determineZone(order.getDestination());
        return rateTable.get(zone.getCode()) * weight;
    }
    
    private ShippingZone determineZone(Address destination) {
        // Zone determination logic
        return zone;
    }
}

Technique 2: Change Reason Analysis

For each method and field, ask: "What kind of business change would require modifying this?"

Changes to validation rules → Methods A, B, C, Field X, Y
Changes to shipping rates → Methods D, E, F, Fields Z, W
Changes to payment processing → Methods G, H, Fields V

Each distinct category of change reason represents a separate responsibility. Group the elements by their change drivers.

Change Reason Analysis Example
Element	Change Reason Category	Likely Stakeholder
validateOrder()	Business rules change	Business Analyst
validationErrors	Business rules change	Business Analyst
calculateShipping()	Shipping rate updates	Logistics Team
rateTable	Shipping rate updates	Logistics Team
processPayment()	Payment gateway changes	Finance Team
paymentGateway	Payment gateway changes	Finance Team

Technique 3: Naming Analysis

Examine method names for clues about hidden responsibilities:

Methods with prefixes like validate*, calculate*, format*, send* suggest distinct concerns
Methods that could reasonably belong to a class named after that prefix are extraction candidates
If you can describe a group of methods as "all the X-related methods," X is likely a separate responsibility

Technique 4: Parameter Clustering

Look at method parameters. Methods that consistently receive the same types of parameters often belong together:

Methods taking User and Credentials → Authentication responsibility
Methods taking Order and ShippingAddress → Shipping responsibility
Methods taking Report and DateRange → Reporting responsibility

The Rule of Three

Don't rush to extract after finding just one or two methods. A meaningful responsibility typically involves three or more methods and at least two fields. Extracting less than this often creates classes too trivial to justify their existence, increasing complexity without improving design.

The Extraction Process: Step by Step

Once you've identified an extraction candidate, the actual extraction should follow a disciplined, incremental process. This isn't a single "move things around" operation—it's a sequence of small, verifiable steps that maintains system correctness throughout.

The Seven-Step Extraction Protocol:

Step-by-Step Extraction Protocol

•Characterize the extraction target — Document exactly which fields and methods will be extracted. Confirm they form a cohesive unit.
•Create the new class shell — Create an empty class with an appropriate name that describes the extracted responsibility.
•Move fields first — Copy the identified fields to the new class. Keep them in the original class temporarily.
•Move methods incrementally — Move methods one at a time, updating references to use the new class's fields.
•Establish the relationship — Create a field in the original class that holds an instance of the extracted class.
•Update the original class — Replace direct field access with delegation to the extracted class.
•Remove duplication — Delete the now-redundant fields and methods from the original class.

Let's walk through a complete extraction. We'll transform the problematic OrderProcessor from earlier into a clean design.

extraction_step_1_new_class.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
// Step 2-3: Create new class with moved fields
public class OrderValidator {
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    public OrderValidator(ValidationRules rules) {
        this.rules = rules;
        this.validationErrors = new ArrayList<>();
        this.isValidated = false;
    }
}
 
// Step 4: Move methods
public class OrderValidator {
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    public OrderValidator(ValidationRules rules) {
        this.rules = rules;
        this.validationErrors = new ArrayList<>();
        this.isValidated = false;
    }
    
    // Method moved from OrderProcessor
    public boolean validate(Order order) {
        validationErrors.clear();
        for (Rule rule : rules.getRules()) {
            if (!rule.check(order)) {
                validationErrors.add(rule.getMessage());
            }
        }
        isValidated = validationErrors.isEmpty();
        return isValidated;
    }
    
    public List<String> getValidationErrors() {
        return new ArrayList<>(validationErrors);
    }
    
    public boolean isValidated() {
        return isValidated;
    }
}

extraction_step_5_7_updated_original.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
// Step 5-7: Establish relationship and delegate
public class OrderProcessor {
    // Composition: OrderProcessor HAS-A OrderValidator
    private final OrderValidator validator;
    
    // Shipping fields remain (separate extraction possible later)
    private ShippingZone zone;
    private double weight;
    private Map<String, Double> rateTable;
    
    public OrderProcessor(ValidationRules rules, Map<String, Double> rateTable) {
        this.validator = new OrderValidator(rules);
        this.rateTable = rateTable;
    }
    
    // Delegation to extracted class
    public boolean validate(Order order) {
        return validator.validate(order);
    }
    
    public List<String> getValidationErrors() {
        return validator.getValidationErrors();
    }
    
    // Shipping methods remain until separately extracted
    public double calculateShipping(Order order) {
        weight = order.getTotalWeight();
        zone = determineZone(order.getDestination());
        return rateTable.get(zone.getCode()) * weight;
    }
    
    private ShippingZone determineZone(Address destination) {
        // Zone determination logic
        return zone;
    }
}

Test After Every Step

Run your test suite after each step. If tests fail, you know exactly which change caused the problem. This incremental verification is what makes extraction safe rather than risky.

Deciding on the Relationship Type

After extraction, you must establish an appropriate relationship between the original class and the extracted class. This decision significantly impacts the design's flexibility, testability, and clarity.

Option 1: Direct Composition (Most Common)

The original class creates and owns the extracted class. This is appropriate when:

The extracted responsibility is an intrinsic part of the original class's operation
The extracted class has no need for independent existence
Lifecycle management is straightforward (create at construction, destroy with parent)

direct_composition.java
Java
1
2
3
4
5
6
7
8
// Direct composition: OrderProcessor creates its own validator
public class OrderProcessor {
    private final OrderValidator validator;  // Created internally
    
    public OrderProcessor(ValidationRules rules) {
        this.validator = new OrderValidator(rules);  // Tight coupling
    }
}

Option 2: Dependency Injection

The extracted class is passed into the original class. This is preferred when:

The extracted class might have different implementations
Testing requires substituting mock or stub implementations
The extracted class has broader applicability beyond this single use

dependency_injection.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Dependency injection: Validator is provided
public class OrderProcessor {
    private final OrderValidator validator;  // Injected dependency
    
    public OrderProcessor(OrderValidator validator) {
        this.validator = validator;  // Loose coupling, testable
    }
}
 
// Even better: Depend on abstraction
public class OrderProcessor {
    private final Validator<Order> validator;  // Interface dependency
    
    public OrderProcessor(Validator<Order> validator) {
        this.validator = validator;  // Maximum flexibility
    }
}

Option 3: Expose the Extracted Class

In some cases, the extracted class should be directly accessible to clients of the original class. This is appropriate when:

Clients need to interact with the extracted responsibility independently
The original class is primarily a coordinator
Breaking the Law of Demeter is justified by API clarity

Delegation (Hidden)

•Original class wraps all calls
•Extracted class is an implementation detail
•API surface remains stable
•order.validate() delegates to validator

Exposure (Visible)

•Original class provides access to extracted class
•Clients interact with extracted class directly
•More flexible but more coupled API
•order.getValidator().validate()

When in Doubt, Inject

If you're unsure whether to use direct composition or injection, prefer injection. It's always easier to create convenience constructors that use default implementations than to refactor direct composition into injection later. Injection provides testability and flexibility with minimal overhead.

Handling Bidirectional Dependencies

One of the trickiest aspects of extraction is handling situations where the extracted code needs access to the original class. This creates a bidirectional dependency—the original has the extracted, and the extracted needs the original.

The Problem:

bidirectional_problem.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
// Problematic: The extracted validation needs data from OrderProcessor
public class OrderValidator {
    public boolean validate(Order order) {
        // Need to check order against the processor's rate table!
        // But OrderValidator doesn't have access to OrderProcessor
        double shippingCost = ???;  // How to get this?
        
        if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
    }
}

Solution 1: Pass Required Data as Parameters

The cleanest solution is to make the extracted class's methods accept all required data as parameters. This eliminates the dependency and makes the method's requirements explicit.

parameter_passing.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Solution 1: Pass shipping cost as parameter
public class OrderValidator {
    public boolean validate(Order order, double shippingCost) {
        // Now we have everything we need
        if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
        return validationErrors.isEmpty();
    }
}
 
// Caller provides the data
public class OrderProcessor {
    public boolean validate(Order order) {
        double shipping = calculateShipping(order);
        return validator.validate(order, shipping);  // Pass required data
    }
}

Solution 2: Inject Required Collaborator

If the extracted class needs ongoing access to certain functionality (not just data), inject the collaborator as a dependency.

inject_collaborator.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
// Solution 2: Inject the shipping calculator
public interface ShippingCalculator {
    double calculateShipping(Order order);
}
 
public class OrderValidator {
    private final ShippingCalculator shippingCalculator;
    
    public OrderValidator(ValidationRules rules, ShippingCalculator shippingCalculator) {
        this.rules = rules;
        this.shippingCalculator = shippingCalculator;
    }
    
    public boolean validate(Order order) {
        double shipping = shippingCalculator.calculateShipping(order);
        if (order.getTotal() < minimumOrder && shipping > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
        return validationErrors.isEmpty();
    }
}
 
// OrderProcessor implements ShippingCalculator
public class OrderProcessor implements ShippingCalculator {
    private final OrderValidator validator;
    
    public OrderProcessor(ValidationRules rules) {
        // Pass 'this' as the shipping calculator
        this.validator = new OrderValidator(rules, this);
    }
    
    @Override
    public double calculateShipping(Order order) {
        // Implementation
    }
}

Avoid Circular References

If you find yourself passing 'this' directly (not via an interface), reconsider your extraction. Circular object references create tight coupling, complicate garbage collection, and often indicate the extraction boundary was incorrectly defined.

Validating the Extraction

After completing an extraction, you must verify that it actually improved the design. A poorly executed extraction can make code worse—more fragmented, more coupled, harder to understand.

Validation Checklist:

Post-Extraction Validation Criteria

•Clear Naming — Can you name the extracted class with a noun that describes a genuine concept, not an arbitrary grouping?
•Single Responsibility — Does the extracted class have one reason to change? Could you describe its responsibility in one sentence without using 'and'?
•High Cohesion — Do most methods in the extracted class use most of its fields? Are there sub-clusters that suggest further extraction needed?
•Minimal Coupling — Does the extracted class have few dependencies? Does it depend on abstractions rather than implementations where possible?
•Reduced Original Complexity — Is the original class simpler? Are its remaining responsibilities clearer?
•Easier Testing — Can you test the extracted class in isolation? Are tests simpler than before?
•Improved Reusability — Could the extracted class be used in other contexts? Would such reuse make sense?

Warning Signs of Bad Extraction
Warning Sign	Likely Problem	Corrective Action
Extracted class has 1-2 trivial methods	Over-extraction	Merge back into original class
Heavy data passing between classes	Wrong extraction boundary	Rethink what belongs together
Can't name it without saying 'Helper' or 'Manager'	Arbitrary grouping	Re-analyze for genuine responsibilities
Extracted class needs many original's fields	Inappropriate extraction	Fields should move with their methods
Tests became more complex	Extraction added coupling	Consider simpler design

The Explain It Test

Try explaining the new design to a colleague. If you struggle to explain why two things are in separate classes, or why they're connected the way they are, the design probably isn't clear. Good extractions create obvious, natural-feeling separations.

Common Extraction Patterns

Certain extraction patterns recur across many codebases. Recognizing these patterns accelerates your extraction decisions and ensures you're applying proven approaches.

Pattern: Strategy Extraction

When a class contains multiple algorithms for the same task (often in switch statements or if-else chains), extract each algorithm into its own strategy class.

Before:

Class has calculateTax() with cases for US, EU, Asia
Adding new regions requires modifying the class

After:

TaxStrategy interface with calculate() method
USTaxStrategy, EUTaxStrategy, AsiaTaxStrategy implementations
Original class delegates to injected strategy

strategy_extraction.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
// Before: Algorithm selection via switch
public class TaxCalculator {
    public double calculateTax(Order order, Region region) {
        switch (region) {
            case US: return calculateUSTax(order);
            case EU: return calculateEUTax(order);
            case ASIA: return calculateAsiaTax(order);
            default: throw new IllegalArgumentException();
        }
    }
    // ... multiple algorithm implementations
}
 
// After: Strategy extraction
public interface TaxStrategy {
    double calculate(Order order);
}
 
public class USTaxStrategy implements TaxStrategy { /* ... */ }
public class EUTaxStrategy implements TaxStrategy { /* ... */ }
 
public class TaxCalculator {
    private final TaxStrategy strategy;
    
    public TaxCalculator(TaxStrategy strategy) {
        this.strategy = strategy;
    }
    
    public double calculateTax(Order order) {
        return strategy.calculate(order);
    }
}

Summary: Mastering Class Extraction

Class extraction is the workhorse refactoring for achieving SRP compliance. When executed systematically, it transforms bloated, multi-purpose classes into focused, single-responsibility components.

Key Takeaways

•Identify candidates systematically — Use field affinity, change reason, naming, and parameter clustering analysis to find genuine responsibilities.
•Follow a disciplined process — Move fields first, then methods incrementally, testing after each step to maintain correctness.
•Choose relationships thoughtfully — Prefer dependency injection for flexibility and testability; use direct composition only for tightly bound internals.
•Handle bidirectional dependencies carefully — Pass data as parameters or inject collaborators via interfaces; avoid circular object references.
•Validate every extraction — Ensure the extracted class has a clear name, single responsibility, high cohesion, and minimal coupling.
•Recognize common patterns — Strategy extraction, value object extraction, and service extraction are recurring solutions to common SRP violations.

What's next:

With class extraction mastered, the next page explores splitting responsibilities—the higher-level skill of determining how to divide a complex class when multiple valid extraction boundaries exist. We'll learn frameworks for making these judgment calls and avoiding both over-extraction and under-extraction.

Page Complete

You now understand the complete process of class extraction—from identifying candidates through multiple analytical techniques, to executing extractions safely, to validating the resulting design. Practice this technique repeatedly until it becomes second nature.

1 / 4

Loading learning content...

System Design (LLD)Refactoring for SRP

Refactoring for Single Responsibility Principle

LevelIntermediate

Duration90 mins

TopicRefactoring for SRP

1 / 4

Extracting Classes

The Art of Surgical Class Extraction

What You Will Learn

Understanding Class Extraction

The fundamental principle:

The Cohesion Test

When to extract vs. when to leave alone:

Class extraction is not always the right answer. It's appropriate when:

Distinct responsibilities have merged — The class handles multiple unrelated concerns that change for different reasons
Cohesive clusters exist — Groups of methods operate primarily on subsets of the class's fields
Reuse is blocked — Part of the class's functionality could be reused, but the entire class must be included
Testing is complicated — Testing one aspect requires setting up unrelated parts of the class
The class is growing uncontrollably — Each feature request adds more code to an already large class

Extraction is not appropriate when:

All methods truly collaborate — Every method uses most of the class's state
Extraction would create trivial classes — The "extracted" class would have one method and one field
Coupling would increase — The extracted class would need extensive access to the original's internals
The abstraction is forced — No natural name exists for the extracted responsibility

Identifying Extraction Candidates

Technique 1: Field Affinity Analysis

field_affinity_example.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
// Before extraction: A class with two distinct field clusters
public class OrderProcessor {
    // Cluster 1: Order validation fields
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    // Cluster 2: Shipping calculation fields
    private ShippingZone zone;
    private double weight;
    private Map<String, Double> rateTable;
    
    // Cluster 1 methods: Only use validation fields
    public boolean validate(Order order) {
        validationErrors.clear();
        for (Rule rule : rules.getRules()) {
            if (!rule.check(order)) {
                validationErrors.add(rule.getMessage());
            }
        }
        isValidated = validationErrors.isEmpty();
        return isValidated;
    }
    
    public List<String> getValidationErrors() {
        return new ArrayList<>(validationErrors);
    }
    
    // Cluster 2 methods: Only use shipping fields
    public double calculateShipping(Order order) {
        weight = order.getTotalWeight();
        zone = determineZone(order.getDestination());
        return rateTable.get(zone.getCode()) * weight;
    }
    
    private ShippingZone determineZone(Address destination) {
        // Zone determination logic
        return zone;
    }
}

Technique 2: Change Reason Analysis

For each method and field, ask: "What kind of business change would require modifying this?"

Changes to validation rules → Methods A, B, C, Field X, Y
Changes to shipping rates → Methods D, E, F, Fields Z, W
Changes to payment processing → Methods G, H, Fields V

Each distinct category of change reason represents a separate responsibility. Group the elements by their change drivers.

Change Reason Analysis Example
Element	Change Reason Category	Likely Stakeholder
validateOrder()	Business rules change	Business Analyst
validationErrors	Business rules change	Business Analyst
calculateShipping()	Shipping rate updates	Logistics Team
rateTable	Shipping rate updates	Logistics Team
processPayment()	Payment gateway changes	Finance Team
paymentGateway	Payment gateway changes	Finance Team

Technique 3: Naming Analysis

Examine method names for clues about hidden responsibilities:

Methods with prefixes like validate*, calculate*, format*, send* suggest distinct concerns
Methods that could reasonably belong to a class named after that prefix are extraction candidates
If you can describe a group of methods as "all the X-related methods," X is likely a separate responsibility

Technique 4: Parameter Clustering

Look at method parameters. Methods that consistently receive the same types of parameters often belong together:

Methods taking User and Credentials → Authentication responsibility
Methods taking Order and ShippingAddress → Shipping responsibility
Methods taking Report and DateRange → Reporting responsibility

The Rule of Three

The Extraction Process: Step by Step

The Seven-Step Extraction Protocol:

Step-by-Step Extraction Protocol

•Characterize the extraction target — Document exactly which fields and methods will be extracted. Confirm they form a cohesive unit.
•Create the new class shell — Create an empty class with an appropriate name that describes the extracted responsibility.
•Move fields first — Copy the identified fields to the new class. Keep them in the original class temporarily.
•Move methods incrementally — Move methods one at a time, updating references to use the new class's fields.
•Establish the relationship — Create a field in the original class that holds an instance of the extracted class.
•Update the original class — Replace direct field access with delegation to the extracted class.
•Remove duplication — Delete the now-redundant fields and methods from the original class.

Let's walk through a complete extraction. We'll transform the problematic OrderProcessor from earlier into a clean design.

extraction_step_1_new_class.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
// Step 2-3: Create new class with moved fields
public class OrderValidator {
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    public OrderValidator(ValidationRules rules) {
        this.rules = rules;
        this.validationErrors = new ArrayList<>();
        this.isValidated = false;
    }
}
 
// Step 4: Move methods
public class OrderValidator {
    private ValidationRules rules;
    private List<String> validationErrors;
    private boolean isValidated;
    
    public OrderValidator(ValidationRules rules) {
        this.rules = rules;
        this.validationErrors = new ArrayList<>();
        this.isValidated = false;
    }
    
    // Method moved from OrderProcessor
    public boolean validate(Order order) {
        validationErrors.clear();
        for (Rule rule : rules.getRules()) {
            if (!rule.check(order)) {
                validationErrors.add(rule.getMessage());
            }
        }
        isValidated = validationErrors.isEmpty();
        return isValidated;
    }
    
    public List<String> getValidationErrors() {
        return new ArrayList<>(validationErrors);
    }
    
    public boolean isValidated() {
        return isValidated;
    }
}

extraction_step_5_7_updated_original.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
// Step 5-7: Establish relationship and delegate
public class OrderProcessor {
    // Composition: OrderProcessor HAS-A OrderValidator
    private final OrderValidator validator;
    
    // Shipping fields remain (separate extraction possible later)
    private ShippingZone zone;
    private double weight;
    private Map<String, Double> rateTable;
    
    public OrderProcessor(ValidationRules rules, Map<String, Double> rateTable) {
        this.validator = new OrderValidator(rules);
        this.rateTable = rateTable;
    }
    
    // Delegation to extracted class
    public boolean validate(Order order) {
        return validator.validate(order);
    }
    
    public List<String> getValidationErrors() {
        return validator.getValidationErrors();
    }
    
    // Shipping methods remain until separately extracted
    public double calculateShipping(Order order) {
        weight = order.getTotalWeight();
        zone = determineZone(order.getDestination());
        return rateTable.get(zone.getCode()) * weight;
    }
    
    private ShippingZone determineZone(Address destination) {
        // Zone determination logic
        return zone;
    }
}

Test After Every Step

Run your test suite after each step. If tests fail, you know exactly which change caused the problem. This incremental verification is what makes extraction safe rather than risky.

Deciding on the Relationship Type

Option 1: Direct Composition (Most Common)

The original class creates and owns the extracted class. This is appropriate when:

The extracted responsibility is an intrinsic part of the original class's operation
The extracted class has no need for independent existence
Lifecycle management is straightforward (create at construction, destroy with parent)

direct_composition.java
Java
1
2
3
4
5
6
7
8
// Direct composition: OrderProcessor creates its own validator
public class OrderProcessor {
    private final OrderValidator validator;  // Created internally
    
    public OrderProcessor(ValidationRules rules) {
        this.validator = new OrderValidator(rules);  // Tight coupling
    }
}

Option 2: Dependency Injection

The extracted class is passed into the original class. This is preferred when:

The extracted class might have different implementations
Testing requires substituting mock or stub implementations
The extracted class has broader applicability beyond this single use

dependency_injection.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Dependency injection: Validator is provided
public class OrderProcessor {
    private final OrderValidator validator;  // Injected dependency
    
    public OrderProcessor(OrderValidator validator) {
        this.validator = validator;  // Loose coupling, testable
    }
}
 
// Even better: Depend on abstraction
public class OrderProcessor {
    private final Validator<Order> validator;  // Interface dependency
    
    public OrderProcessor(Validator<Order> validator) {
        this.validator = validator;  // Maximum flexibility
    }
}

Option 3: Expose the Extracted Class

In some cases, the extracted class should be directly accessible to clients of the original class. This is appropriate when:

Clients need to interact with the extracted responsibility independently
The original class is primarily a coordinator
Breaking the Law of Demeter is justified by API clarity

Delegation (Hidden)

•Original class wraps all calls
•Extracted class is an implementation detail
•API surface remains stable
•order.validate() delegates to validator

Exposure (Visible)

•Original class provides access to extracted class
•Clients interact with extracted class directly
•More flexible but more coupled API
•order.getValidator().validate()

When in Doubt, Inject

Handling Bidirectional Dependencies

The Problem:

bidirectional_problem.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
// Problematic: The extracted validation needs data from OrderProcessor
public class OrderValidator {
    public boolean validate(Order order) {
        // Need to check order against the processor's rate table!
        // But OrderValidator doesn't have access to OrderProcessor
        double shippingCost = ???;  // How to get this?
        
        if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
    }
}

Solution 1: Pass Required Data as Parameters

The cleanest solution is to make the extracted class's methods accept all required data as parameters. This eliminates the dependency and makes the method's requirements explicit.

parameter_passing.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Solution 1: Pass shipping cost as parameter
public class OrderValidator {
    public boolean validate(Order order, double shippingCost) {
        // Now we have everything we need
        if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
        return validationErrors.isEmpty();
    }
}
 
// Caller provides the data
public class OrderProcessor {
    public boolean validate(Order order) {
        double shipping = calculateShipping(order);
        return validator.validate(order, shipping);  // Pass required data
    }
}

Solution 2: Inject Required Collaborator

If the extracted class needs ongoing access to certain functionality (not just data), inject the collaborator as a dependency.

inject_collaborator.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
// Solution 2: Inject the shipping calculator
public interface ShippingCalculator {
    double calculateShipping(Order order);
}
 
public class OrderValidator {
    private final ShippingCalculator shippingCalculator;
    
    public OrderValidator(ValidationRules rules, ShippingCalculator shippingCalculator) {
        this.rules = rules;
        this.shippingCalculator = shippingCalculator;
    }
    
    public boolean validate(Order order) {
        double shipping = shippingCalculator.calculateShipping(order);
        if (order.getTotal() < minimumOrder && shipping > freeShippingThreshold) {
            addError("Order too small for paid shipping");
        }
        return validationErrors.isEmpty();
    }
}
 
// OrderProcessor implements ShippingCalculator
public class OrderProcessor implements ShippingCalculator {
    private final OrderValidator validator;
    
    public OrderProcessor(ValidationRules rules) {
        // Pass 'this' as the shipping calculator
        this.validator = new OrderValidator(rules, this);
    }
    
    @Override
    public double calculateShipping(Order order) {
        // Implementation
    }
}

Avoid Circular References

Validating the Extraction

After completing an extraction, you must verify that it actually improved the design. A poorly executed extraction can make code worse—more fragmented, more coupled, harder to understand.

Validation Checklist:

Post-Extraction Validation Criteria

•Clear Naming — Can you name the extracted class with a noun that describes a genuine concept, not an arbitrary grouping?
•Single Responsibility — Does the extracted class have one reason to change? Could you describe its responsibility in one sentence without using 'and'?
•High Cohesion — Do most methods in the extracted class use most of its fields? Are there sub-clusters that suggest further extraction needed?
•Minimal Coupling — Does the extracted class have few dependencies? Does it depend on abstractions rather than implementations where possible?
•Reduced Original Complexity — Is the original class simpler? Are its remaining responsibilities clearer?
•Easier Testing — Can you test the extracted class in isolation? Are tests simpler than before?
•Improved Reusability — Could the extracted class be used in other contexts? Would such reuse make sense?

Warning Signs of Bad Extraction
Warning Sign	Likely Problem	Corrective Action
Extracted class has 1-2 trivial methods	Over-extraction	Merge back into original class
Heavy data passing between classes	Wrong extraction boundary	Rethink what belongs together
Can't name it without saying 'Helper' or 'Manager'	Arbitrary grouping	Re-analyze for genuine responsibilities
Extracted class needs many original's fields	Inappropriate extraction	Fields should move with their methods
Tests became more complex	Extraction added coupling	Consider simpler design

The Explain It Test

Common Extraction Patterns

Certain extraction patterns recur across many codebases. Recognizing these patterns accelerates your extraction decisions and ensures you're applying proven approaches.

Pattern: Strategy Extraction

When a class contains multiple algorithms for the same task (often in switch statements or if-else chains), extract each algorithm into its own strategy class.

Before:

Class has calculateTax() with cases for US, EU, Asia
Adding new regions requires modifying the class

After:

TaxStrategy interface with calculate() method
USTaxStrategy, EUTaxStrategy, AsiaTaxStrategy implementations
Original class delegates to injected strategy

strategy_extraction.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
// Before: Algorithm selection via switch
public class TaxCalculator {
    public double calculateTax(Order order, Region region) {
        switch (region) {
            case US: return calculateUSTax(order);
            case EU: return calculateEUTax(order);
            case ASIA: return calculateAsiaTax(order);
            default: throw new IllegalArgumentException();
        }
    }
    // ... multiple algorithm implementations
}
 
// After: Strategy extraction
public interface TaxStrategy {
    double calculate(Order order);
}
 
public class USTaxStrategy implements TaxStrategy { /* ... */ }
public class EUTaxStrategy implements TaxStrategy { /* ... */ }
 
public class TaxCalculator {
    private final TaxStrategy strategy;
    
    public TaxCalculator(TaxStrategy strategy) {
        this.strategy = strategy;
    }
    
    public double calculateTax(Order order) {
        return strategy.calculate(order);
    }
}

Summary: Mastering Class Extraction

Class extraction is the workhorse refactoring for achieving SRP compliance. When executed systematically, it transforms bloated, multi-purpose classes into focused, single-responsibility components.

Key Takeaways

•Identify candidates systematically — Use field affinity, change reason, naming, and parameter clustering analysis to find genuine responsibilities.
•Follow a disciplined process — Move fields first, then methods incrementally, testing after each step to maintain correctness.
•Choose relationships thoughtfully — Prefer dependency injection for flexibility and testability; use direct composition only for tightly bound internals.
•Handle bidirectional dependencies carefully — Pass data as parameters or inject collaborators via interfaces; avoid circular object references.
•Validate every extraction — Ensure the extracted class has a clear name, single responsibility, high cohesion, and minimal coupling.
•Recognize common patterns — Strategy extraction, value object extraction, and service extraction are recurring solutions to common SRP violations.

What's next:

Page Complete

1 / 4