6c:T45d,**When to extract vs. when to leave alone:** Class extraction is not always the right answer. It's appropriate when: 1. **Distinct responsibilities have merged** — The class handles multiple unrelated concerns that change for different reasons 2. **Cohesive clusters exist** — Groups of methods operate primarily on subsets of the class's fields 3. **Reuse is blocked** — Part of the class's functionality could be reused, but the entire class must be included 4. **Testing is complicated** — Testing one aspect requires setting up unrelated parts of the class 5. **The class is growing uncontrollably** — Each feature request adds more code to an already large class Extraction is *not* appropriate when: 1. **All methods truly collaborate** — Every method uses most of the class's state 2. **Extraction would create trivial classes** — The "extracted" class would have one method and one field 3. **Coupling would increase** — The extracted class would need extensive access to the original's internals 4. **The abstraction is forced** — No natural name exists for the extracted responsibility6d:T504,// Before extraction: A class with two distinct field clusters public class OrderProcessor { // Cluster 1: Order validation fields private ValidationRules rules; private List validationErrors; private boolean isValidated; // Cluster 2: Shipping calculation fields private ShippingZone zone; private double weight; private Map 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 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; } }6e:T551,// Before extraction: A class with two distinct field clusters class OrderProcessor { // Cluster 1: Order validation fields private rules: ValidationRules; private validationErrors: string[] = []; private isValidated: boolean = false; // Cluster 2: Shipping calculation fields private zone: ShippingZone | null = null; private weight: number = 0; private rateTable: Map; // Cluster 1 methods: Only use validation fields validate(order: Order): boolean { this.validationErrors = []; for (const rule of this.rules.getRules()) { if (!rule.check(order)) { this.validationErrors.push(rule.getMessage()); } } this.isValidated = this.validationErrors.length === 0; return this.isValidated; } getValidationErrors(): string[] { return [...this.validationErrors]; } // Cluster 2 methods: Only use shipping fields calculateShipping(order: Order): number { this.weight = order.getTotalWeight(); this.zone = this.determineZone(order.getDestination()); return (this.rateTable.get(this.zone.getCode()) ?? 0) * this.weight; } private determineZone(destination: Address): ShippingZone { // Zone determination logic return this.zone!; } }6f:T4ed,// Step 2-3: Create new class with moved fields public class OrderValidator { private ValidationRules rules; private List 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 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 getValidationErrors() { return new ArrayList<>(validationErrors); } public boolean isValidated() { return isValidated; } }70:T44a,// Step 2-3: Create new class with moved fields class OrderValidator { private rules: ValidationRules; private validationErrors: string[] = []; private isValidated: boolean = false; constructor(rules: ValidationRules) { this.rules = rules; } } // Step 4: Move methods class OrderValidator { private rules: ValidationRules; private validationErrors: string[] = []; private isValidated: boolean = false; constructor(rules: ValidationRules) { this.rules = rules; } // Method moved from OrderProcessor validate(order: Order): boolean { this.validationErrors = []; for (const rule of this.rules.getRules()) { if (!rule.check(order)) { this.validationErrors.push(rule.getMessage()); } } this.isValidated = this.validationErrors.length === 0; return this.isValidated; } getValidationErrors(): string[] { return [...this.validationErrors]; } isOrderValidated(): boolean { return this.isValidated; } }71:T496,// 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 rateTable; public OrderProcessor(ValidationRules rules, Map rateTable) { this.validator = new OrderValidator(rules); this.rateTable = rateTable; } // Delegation to extracted class public boolean validate(Order order) { return validator.validate(order); } public List 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; } }72:T4c3,// Step 5-7: Establish relationship and delegate class OrderProcessor { // Composition: OrderProcessor HAS-A OrderValidator private readonly validator: OrderValidator; // Shipping fields remain (separate extraction possible later) private zone: ShippingZone | null = null; private weight: number = 0; private rateTable: Map; constructor(rules: ValidationRules, rateTable: Map) { this.validator = new OrderValidator(rules); this.rateTable = rateTable; } // Delegation to extracted class validate(order: Order): boolean { return this.validator.validate(order); } getValidationErrors(): string[] { return this.validator.getValidationErrors(); } // Shipping methods remain until separately extracted calculateShipping(order: Order): number { this.weight = order.getTotalWeight(); this.zone = this.determineZone(order.getDestination()); return (this.rateTable.get(this.zone.getCode()) ?? 0) * this.weight; } private determineZone(destination: Address): ShippingZone { // Zone determination logic return this.zone!; } }73:T47c,// 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 } }65:{"json":{"id":"seed_104149474ffbe1d67e7209d852321be1","slug":"refactoring-for-srp","category":"System Design (LLD)","topic":"Refactoring for SRP","title":"Refactoring for Single Responsibility Principle","description":"Master the art of transforming SRP-violating code into well-structured, single-responsibility designs through systematic class extraction, responsibility splitting, cohesion maintenance, and step-by-step refactoring techniques.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_8f79ffb2a60e54f6f30c52074f1c645f","title":"Extracting Classes","order":0,"content":[{"id":"opening-hook","title":"The Art of Surgical Class Extraction","content":[{"data":{"content":"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.\n\nThe 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.\n\nClass 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."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"understanding-class-extraction","title":"Understanding Class Extraction","content":[{"data":{"content":"**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.\n\nThis 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.\"\n\n**The fundamental principle:**\n\nA 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."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Cohesion Test","content":"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.","variant":"tip"},"type":"callout"},{"data":{"content":"$6c"},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"identifying-extraction-candidates","title":"Identifying Extraction Candidates","content":[{"data":{"content":"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.\n\n**Technique 1: Field Affinity Analysis**\n\nGroup 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.\n\nMethods 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."},"type":"text"},{"data":{"fileName":"field_affinity_example.java","languages":[{"code":"$6d","label":"Java","value":"java"},{"code":"$6e","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Technique 2: Change Reason Analysis**\n\nFor each method and field, ask: \"What kind of business change would require modifying this?\"\n\n- Changes to validation rules → Methods A, B, C, Field X, Y\n- Changes to shipping rates → Methods D, E, F, Fields Z, W\n- Changes to payment processing → Methods G, H, Fields V\n\nEach distinct category of change reason represents a separate responsibility. Group the elements by their change drivers."},"type":"text"},{"data":{"rows":[["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"]],"caption":"Change Reason Analysis Example","headers":["Element","Change Reason Category","Likely Stakeholder"]},"type":"table"},{"data":{"content":"**Technique 3: Naming Analysis**\n\nExamine method names for clues about hidden responsibilities:\n\n- Methods with prefixes like `validate*`, `calculate*`, `format*`, `send*` suggest distinct concerns\n- Methods that could reasonably belong to a class named after that prefix are extraction candidates\n- If you can describe a group of methods as \"all the X-related methods,\" X is likely a separate responsibility\n\n**Technique 4: Parameter Clustering**\n\nLook at method parameters. Methods that consistently receive the same types of parameters often belong together:\n\n- Methods taking `User` and `Credentials` → Authentication responsibility\n- Methods taking `Order` and `ShippingAddress` → Shipping responsibility\n- Methods taking `Report` and `DateRange` → Reporting responsibility"},"type":"text"},{"data":{"icon":"Info","title":"The Rule of Three","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"extraction-process","title":"The Extraction Process: Step by Step","content":[{"data":{"content":"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.\n\n**The Seven-Step Extraction Protocol:**"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"Target","text":"Step-by-Step Extraction Protocol","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"Let's walk through a complete extraction. We'll transform the problematic `OrderProcessor` from earlier into a clean design."},"type":"text"},{"data":{"fileName":"extraction_step_1_new_class.java","languages":[{"code":"$6f","label":"Java","value":"java"},{"code":"$70","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"fileName":"extraction_step_5_7_updated_original.java","languages":[{"code":"$71","label":"Java","value":"java"},{"code":"$72","label":"TypeScript","value":"typescript"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Test After Every Step","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"deciding-relationship","title":"Deciding on the Relationship Type","content":[{"data":{"content":"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.\n\n**Option 1: Direct Composition (Most Common)**\n\nThe original class creates and owns the extracted class. This is appropriate when:\n- The extracted responsibility is an intrinsic part of the original class's operation\n- The extracted class has no need for independent existence\n- Lifecycle management is straightforward (create at construction, destroy with parent)"},"type":"text"},{"data":{"fileName":"direct_composition.java","languages":[{"code":"// Direct composition: OrderProcessor creates its own validator\npublic class OrderProcessor {\n private final OrderValidator validator; // Created internally\n \n public OrderProcessor(ValidationRules rules) {\n this.validator = new OrderValidator(rules); // Tight coupling\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Option 2: Dependency Injection**\n\nThe extracted class is passed into the original class. This is preferred when:\n- The extracted class might have different implementations\n- Testing requires substituting mock or stub implementations\n- The extracted class has broader applicability beyond this single use"},"type":"text"},{"data":{"fileName":"dependency_injection.java","languages":[{"code":"// Dependency injection: Validator is provided\npublic class OrderProcessor {\n private final OrderValidator validator; // Injected dependency\n \n public OrderProcessor(OrderValidator validator) {\n this.validator = validator; // Loose coupling, testable\n }\n}\n\n// Even better: Depend on abstraction\npublic class OrderProcessor {\n private final Validator validator; // Interface dependency\n \n public OrderProcessor(Validator validator) {\n this.validator = validator; // Maximum flexibility\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Option 3: Expose the Extracted Class**\n\nIn some cases, the extracted class should be directly accessible to clients of the original class. This is appropriate when:\n- Clients need to interact with the extracted responsibility independently\n- The original class is primarily a coordinator\n- Breaking the Law of Demeter is justified by API clarity"},"type":"text"},{"data":{"left":[{"data":{"items":["Original class wraps all calls","Extracted class is an implementation detail","API surface remains stable","`order.validate()` delegates to validator"],"title":{"icon":"CheckCircle","text":"Delegation (Hidden)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Original class provides access to extracted class","Clients interact with extracted class directly","More flexible but more coupled API","`order.getValidator().validate()`"],"title":{"icon":"Lightbulb","text":"Exposure (Visible)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"When in Doubt, Inject","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"bidirectional-dependencies","title":"Handling Bidirectional Dependencies","content":[{"data":{"content":"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.\n\n**The Problem:**"},"type":"text"},{"data":{"fileName":"bidirectional_problem.java","languages":[{"code":"// Problematic: The extracted validation needs data from OrderProcessor\npublic class OrderValidator {\n public boolean validate(Order order) {\n // Need to check order against the processor's rate table!\n // But OrderValidator doesn't have access to OrderProcessor\n double shippingCost = ???; // How to get this?\n \n if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {\n addError(\"Order too small for paid shipping\");\n }\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Solution 1: Pass Required Data as Parameters**\n\nThe 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."},"type":"text"},{"data":{"fileName":"parameter_passing.java","languages":[{"code":"// Solution 1: Pass shipping cost as parameter\npublic class OrderValidator {\n public boolean validate(Order order, double shippingCost) {\n // Now we have everything we need\n if (order.getTotal() < minimumOrder && shippingCost > freeShippingThreshold) {\n addError(\"Order too small for paid shipping\");\n }\n return validationErrors.isEmpty();\n }\n}\n\n// Caller provides the data\npublic class OrderProcessor {\n public boolean validate(Order order) {\n double shipping = calculateShipping(order);\n return validator.validate(order, shipping); // Pass required data\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Solution 2: Inject Required Collaborator**\n\nIf the extracted class needs ongoing access to certain functionality (not just data), inject the collaborator as a dependency."},"type":"text"},{"data":{"fileName":"inject_collaborator.java","languages":[{"code":"$73","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Avoid Circular References","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"validating-extraction","title":"Validating the Extraction","content":[{"data":{"content":"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.\n\n**Validation Checklist:**"},"type":"text"},{"data":{"items":["**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?"],"title":{"icon":"CheckCircle","text":"Post-Extraction Validation Criteria","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"rows":[["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"]],"caption":"Warning Signs of Bad Extraction","headers":["Warning Sign","Likely Problem","Corrective Action"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The Explain It Test","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"common-patterns","title":"Common Extraction Patterns","content":[{"data":{"content":"Certain extraction patterns recur across many codebases. Recognizing these patterns accelerates your extraction decisions and ensures you're applying proven approaches."},"type":"text"},{"data":{"tabs":[{"id":"strategy-extraction","label":"Strategy Extraction","content":[{"data":{"content":"**Pattern: Strategy Extraction**\n\nWhen 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.\n\n**Before:**\n- Class has `calculateTax()` with cases for US, EU, Asia\n- Adding new regions requires modifying the class\n\n**After:**\n- `TaxStrategy` interface with `calculate()` method\n- `USTaxStrategy`, `EUTaxStrategy`, `AsiaTaxStrategy` implementations\n- Original class delegates to injected strategy"},"type":"text"},{"data":{"fileName":"strategy_extraction.java","languages":[{"code":"// Before: Algorithm selection via switch\npublic class TaxCalculator {\n public double calculateTax(Order order, Region region) {\n switch (region) {\n case US: return calculateUSTax(order);\n case EU: return calculateEUTax(order);\n case ASIA: return calculateAsiaTax(order);\n default: throw new IllegalArgumentException();\n }\n }\n // ... multiple algorithm implementations\n}\n\n// After: Strategy extraction\npublic interface TaxStrategy {\n double calculate(Order order);\n}\n\npublic class USTaxStrategy implements TaxStrategy { /* ... */ }\npublic class EUTaxStrategy implements TaxStrategy { /* ... */ }\n\npublic class TaxCalculator {\n private final TaxStrategy strategy;\n \n public TaxCalculator(TaxStrategy strategy) {\n this.strategy = strategy;\n }\n \n public double calculateTax(Order order) {\n return strategy.calculate(order);\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"}],"titleIcon":"Zap"},{"id":"value-object-extraction","label":"Value Object","content":[{"data":{"content":"**Pattern: Value Object Extraction**\n\nWhen multiple fields travel together and have operations that apply to them as a group, extract them into a value object.\n\n**Before:**\n- Class has `streetAddress`, `city`, `state`, `zipCode` fields\n- Multiple methods format, validate, or manipulate these together\n\n**After:**\n- `Address` value object with formatting and validation methods\n- Original class has single `Address` field\n- Address-related logic lives with address data"},"type":"text"},{"data":{"fileName":"value_object_extraction.java","languages":[{"code":"// Before: Primitive obsession\npublic class Customer {\n private String streetAddress;\n private String city;\n private String state;\n private String zipCode;\n \n public String getFormattedAddress() {\n return streetAddress + \"\n\" + city + \", \" + state + \" \" + zipCode;\n }\n \n public boolean isValidZipCode() {\n return zipCode.matches(\"\\\\d{5}(-\\\\d{4})?\");\n }\n // ... more address-related methods\n}\n\n// After: Value object extraction\npublic class Address {\n private final String street;\n private final String city;\n private final String state;\n private final String zipCode;\n \n public String format() {\n return street + \"\n\" + city + \", \" + state + \" \" + zipCode;\n }\n \n public boolean isValidZipCode() {\n return zipCode.matches(\"\\\\d{5}(-\\\\d{4})?\");\n }\n}\n\npublic class Customer {\n private Address address; // Single, cohesive field\n \n public String getFormattedAddress() {\n return address.format();\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"}],"titleIcon":"Target"},{"id":"service-extraction","label":"Service Extraction","content":[{"data":{"content":"**Pattern: Service Extraction**\n\nWhen a class contains behavior that doesn't conceptually belong to it—behavior using mostly external data or coordinating between other objects—extract it to a service.\n\n**Before:**\n- `User` class has `sendWelcomeEmail()`, `generateInvoice()`, `syncToExternalCRM()`\n- These operations use User data but aren't intrinsic to User\n\n**After:**\n- `EmailService`, `InvoiceService`, `CRMSyncService`\n- User remains a domain object with intrinsic behavior only\n- Services operate on Users but are separate concerns"},"type":"text"},{"data":{"fileName":"service_extraction.java","languages":[{"code":"// Before: Mixed domain and infrastructure\npublic class User {\n private String email;\n private String name;\n private List orders;\n \n // Domain behavior - belongs here\n public void addOrder(Order order) { orders.add(order); }\n \n // Infrastructure - doesn't belong on domain object\n public void sendWelcomeEmail() {\n SmtpClient client = new SmtpClient();\n client.send(this.email, \"Welcome \" + this.name);\n }\n}\n\n// After: Service extraction\npublic class User {\n private String email;\n private String name;\n private List orders;\n \n // Only domain behavior remains\n public void addOrder(Order order) { orders.add(order); }\n public String getEmail() { return email; }\n public String getName() { return name; }\n}\n\npublic class EmailService {\n private final SmtpClient client;\n \n public void sendWelcome(User user) {\n client.send(user.getEmail(), \"Welcome \" + user.getName());\n }\n}","label":"Java","value":"java"}],"showLineNumbers":true},"type":"code"}],"titleIcon":"Sparkles"}]},"type":"tabs"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Mastering Class Extraction","content":[{"data":{"content":"Class extraction is the workhorse refactoring for achieving SRP compliance. When executed systematically, it transforms bloated, multi-purpose classes into focused, single-responsibility components."},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nWith 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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_f875d37f4c710233f07fe2fc9ac712ed","title":"Splitting Responsibilities","order":1,"content":null,"isLocked":true},{"id":"seed_dd4e3efc25f1e93cd2819a3d2a96d0bb","title":"Maintaining Cohesion After Split","order":2,"content":null,"isLocked":true},{"id":"seed_c4e160781275f999322711933cd514b9","title":"Step-by-Step SRP Refactoring","order":3,"content":null,"isLocked":true}]}}