refactoring-techniques

Complete Refactoring Technique Mastery

You have expert knowledge of all refactoring categories:

1. Composing Methods (9 techniques)

Extract Method, Inline Method, Extract Variable, Inline Temp, Replace Temp with Query, Split Temporary Variable, Remove Assignments to Parameters, Replace Method with Method Object, Substitute Algorithm

2. Moving Features between Objects (8 techniques)

Move Method, Move Field, Extract Class, Inline Class, Hide Delegate, Remove Middle Man, Introduce Foreign Method, Introduce Local Extension

3. Organizing Data (15 techniques)

Self Encapsulate Field, Replace Data Value with Object, Change Value to Reference, Change Reference to Value, Replace Array with Object, Duplicate Observed Data, Change Unidirectional Association to Bidirectional, Change Bidirectional Association to Unidirectional, Encapsulate Field, Encapsulate Collection, Replace Magic Number with Symbolic Constant, Replace Type Code with Class, Replace Type Code with Subclasses, Replace Type Code with State/Strategy, Replace Subclass with Fields

4. Simplifying Conditional Expressions (8 techniques)

Decompose Conditional, Consolidate Conditional Expression, Consolidate Duplicate Conditional Fragments, Remove Control Flag, Replace Nested Conditional with Guard Clauses, Replace Conditional with Polymorphism, Introduce Null Object, Introduce Assertion

5. Simplifying Method Calls (14 techniques)

Rename Method, Add Parameter, Remove Parameter, Separate Query from Modifier, Parameterize Method, Replace Parameter with Explicit Methods, Preserve Whole Object, Replace Parameter with Method Call, Introduce Parameter Object, Remove Setting Method, Hide Method, Replace Constructor with Factory Method, Replace Error Code with Exception, Replace Exception with Test

6. Dealing with Generalization (12 techniques)

Pull Up Field, Pull Up Method, Pull Up Constructor Body, Push Down Field, Push Down Method, Extract Subclass, Extract Superclass, Extract Interface, Collapse Hierarchy, Form Template Method, Replace Inheritance with Delegation, Replace Delegation with Inheritance

Comprehensive Code Smell to Refactoring Mappings

You have complete knowledge of which refactoring techniques solve specific code smells:

Bloaters

• Long Method → Extract Method, Replace Temp with Query, Replace Method with Method Object, Decompose Conditional
• Large Class → Extract Class, Extract Subclass, Extract Interface, Duplicate Observed Data
• Primitive Obsession → Replace Data Value with Object, Replace Type Code with Class/Subclasses/State, Replace Array with Object
• Long Parameter List → Replace Parameter with Method Call, Preserve Whole Object, Introduce Parameter Object
• Data Clumps → Extract Class, Introduce Parameter Object, Preserve Whole Object

Object-Orientation Abusers

• Switch Statements → Replace Conditional with Polymorphism, Replace Type Code with Subclasses/State
• Temporary Field → Extract Class, Introduce Null Object
• Refused Bequest → Replace Inheritance with Delegation, Push Down Method, Push Down Field
• Alternative Classes with Different Interfaces → Rename Method, Move Method, Extract Superclass

Change Preventers

• Divergent Change → Extract Class
• Shotgun Surgery → Move Method, Move Field, Inline Class
• Parallel Inheritance Hierarchies → Move Method, Move Field

Dispensables

• Comments → Extract Variable, Extract Method, Rename Method, Introduce Assertion
• Duplicate Code → Extract Method, Pull Up Method, Form Template Method, Substitute Algorithm, Extract Class
• Lazy Class → Inline Class, Collapse Hierarchy
• Data Class → Encapsulate Field, Encapsulate Collection, Remove Setting Method, Hide Method
• Dead Code → Delete unused code
• Speculative Generality → Collapse Hierarchy, Inline Class, Remove Parameter, Rename Method

Couplers

• Feature Envy → Move Method, Extract Method
• Inappropriate Intimacy → Move Method, Move Field, Change Bidirectional Association to Unidirectional, Replace Inheritance with Delegation, Hide Delegate
• Message Chains → Hide Delegate, Extract Method
• Middle Man → Remove Middle Man, Inline Method, Replace Delegation with Inheritance
• Incomplete Library Class → Introduce Foreign Method, Introduce Local Extension

SOLID/GRASP Principle Violations

• Single Responsibility Principle → Extract Class, Extract Method, Move Method
• Open/Closed Principle → Replace Conditional with Polymorphism, Replace Type Code with Subclasses
• Liskov Substitution Principle → Replace Inheritance with Delegation, Extract Interface
• Interface Segregation Principle → Extract Interface, Replace Parameter with Explicit Methods
• Dependency Inversion Principle → Replace Constructor with Factory Method, Introduce Parameter Object
• Information Expert (GRASP) → Move Method, Move Field
• High Cohesion (GRASP) → Extract Class, Extract Method
• Low Coupling (GRASP) → Hide Delegate, Remove Middle Man

Refactoring Sequence Dependencies

You understand the optimal order for applying refactoring techniques:

Preparation Sequences

1. Extract Variable → Extract Method → Move Method
2. Self Encapsulate Field → Pull Up Field → Extract Superclass
3. Replace Constructor with Factory Method → Change Value to Reference
4. Inline Temp → Replace Temp with Query → Extract Method

Foundation First

1. Encapsulate Field before other data refactorings
2. Extract Method before Move Method
3. Replace Type Code with Class before Replace Type Code with Subclasses
4. Rename Method before Extract Interface

Opposite Refactorings (Choose One Direction)

• Extract Method ↔ Inline Method
• Extract Class ↔ Inline Class
• Pull Up Method ↔ Push Down Method
• Hide Delegate ↔ Remove Middle Man
• Replace Inheritance with Delegation ↔ Replace Delegation with Inheritance

Complete Refactoring Techniques Encyclopedia

You have detailed knowledge of all 66 refactoring techniques with complete implementation guidance:

---

1. COMPOSING METHODS

1.1 Extract Method

Problem: Code fragment that can be grouped together Solution: Move code to separate method, replace with method call When to Use: Long methods, duplicate code, improve readability Mechanics:

1. Create new method with descriptive name based on method's purpose
2. Copy relevant code fragment to new method
3. Scan for local variables used in fragment
4. Handle read-only variables as parameters
5. Handle modified variables as return values or by reference
6. Replace original code with method call
7. Test thoroughly after each change Eliminates: Duplicate Code, Long Method, Feature Envy Risk Level: Medium

1.2 Inline Method

Problem: Method body more obvious than method itself Solution: Replace method calls with method content, delete method When to Use: Unnecessary method delegation, overly simple methods Mechanics:

1. Verify method is not redefined in subclasses
2. Find all calls to method
3. Replace each call with method body
4. Test after each replacement
5. Delete method definition Eliminates: Speculative Generality Risk Level: Low

1.3 Extract Variable

Problem: Expression that's hard to understand Solution: Place complex expression parts into self-explanatory variables When to Use: Complex expressions, preparing for Extract Method Mechanics:

1. Insert line before expression
2. Declare new variable with descriptive name
3. Assign part of complex expression to variable
4. Replace part of expression with variable
5. Test to ensure behavior unchanged Benefits: Improved readability, clear variable names replace comments Risk Level: Low

1.4 Inline Temp

Problem: Temporary variable assigned simple expression result Solution: Replace variable references with original expression When to Use: Part of Replace Temp with Query, preparing Extract Method Mechanics:

1. Find all usage of temporary variable
2. Replace each usage with right-hand side of assignment
3. Test after each replacement
4. Delete declaration and assignment of temporary Caution: Consider performance impact for expensive operations Risk Level: Low

1.5 Replace Temp with Query

Problem: Expression result placed in local variable for later use Solution: Move expression to separate method, replace variable with method calls When to Use: Same expression in multiple methods, preparing Extract Method Mechanics:

1. Ensure variable assigned to only once
2. Extract right-hand side of assignment into method
3. Replace all references to temp with method call
4. Test after each replacement
5. Delete temporary variable Eliminates: Long Method, Duplicate Code Risk Level: Medium

1.6 Split Temporary Variable

Problem: Local variable used for multiple different intermediate values Solution: Use separate variables for different values When to Use: Variable reuse for unrelated purposes, preparing method extraction Mechanics:

1. At first assignment to variable, change name
2. Change all references to variable up to second assignment
3. Test compilation and execution
4. Repeat for other assignments with different names Benefits: Each variable has single responsibility Risk Level: Low

1.7 Remove Assignments to Parameters

Problem: Value assigned to parameter inside method body Solution: Create local variable, replace parameter modifications When to Use: Prevent side effects, improve code clarity Mechanics:

1. Create local variable and assign parameter value
2. Replace all references to parameter after assignment with new variable
3. Replace assignment to parameter with assignment to local variable Benefits: Each element responsible for one thing, facilitates method extraction Risk Level: Low

1.8 Replace Method with Method Object

Problem: Long method with intertwined local variables preventing Extract Method Solution: Transform method into separate class with variables as fields When to Use: Complex methods that can't be easily extracted Mechanics:

1. Create new class named after method
2. Give class final field for original object and fields for each temporary
3. Give class constructor that takes original object and method parameters
4. Give class method named "compute"
5. Copy original method body into compute method
6. Replace original method with creation and call of new object Eliminates: Long Method Drawback: Increases program complexity Risk Level: High

1.9 Substitute Algorithm

Problem: Replace existing algorithm with new, more efficient implementation Solution: Replace method body with new algorithm When to Use: Algorithm too complex, simpler implementation available Mechanics:

1. Prepare alternative algorithm and ensure it works
2. Run new algorithm against existing tests
3. If behavior identical, replace old algorithm
4. Test to ensure new algorithm works correctly Eliminates: Duplicate Code, Long Method Risk Level: Medium

---

2. MOVING FEATURES BETWEEN OBJECTS

2.1 Move Method

Problem: Method used more in another class than its own Solution: Create new method in recipient class, move code When to Use: Improve class coherence, reduce dependencies Mechanics:

1. Examine all features used by source method in source class
2. Check for other methods on source class called by candidate method
3. Check whether method is polymorphic in subclasses
4. Declare method in target class with similar or exact signature
5. Copy code from source to target, adjust for new environment
6. Determine how to reference correct target object from source
7. Turn source method into delegating method or remove entirely Eliminates: Feature Envy, Shotgun Surgery Risk Level: Medium

2.2 Move Field

Problem: Field used more in another class than its own Solution: Create field in new class, redirect all references When to Use: Put fields where methods that use them are located Mechanics:

1. If field is public, use Encapsulate Field
2. Create field in target class with getting and setting methods
3. Determine how to reference target object from source
4. Replace all references to source field with target field
5. Delete field in source class Eliminates: Shotgun Surgery Risk Level: Medium

2.3 Extract Class

Problem: One class doing work of two Solution: Create new class, move relevant fields and methods When to Use: Classes accumulate responsibilities, maintain Single Responsibility Mechanics:

1. Create new class to represent split-off responsibility
2. Create link from old class to new class
3. Use Move Field on each field you want to move
4. Use Move Method to move methods over one at a time
5. Review and reduce interfaces of both classes
6. Decide whether to expose new class publicly or keep as helper Benefits: Maintains SRP, improves clarity, makes classes more reliable Risk Level: Medium

2.4 Inline Class

Problem: Class does almost nothing, isn't responsible for anything Solution: Move all features to another class, eliminate original When to Use: After features transplanted elsewhere, eliminating needless classes Mechanics:

1. Choose absorbing class (create new one if no obvious candidate)
2. Use Move Field and Move Method to move features
3. Replace all references to inlined class with absorbing class
4. Delete inlined class Eliminates: Lazy Class, Shotgun Surgery, Speculative Generality Risk Level: Medium

2.5 Hide Delegate

Problem: Client gets object B from A, then calls method on B Solution: Create new method in A that delegates to B When to Use: Reduce call chain complexity, minimize client knowledge Mechanics:

1. For each method on delegate, create simple delegating method on server
2. Update client code to call server methods instead of delegate
3. Test after each method delegation
4. Remove delegate accessor or make it private Eliminates: Message Chains, Inappropriate Intimacy Risk Level: Low

2.6 Remove Middle Man

Problem: Class has too many methods that simply delegate Solution: Delete delegating methods, force direct calls When to Use: Server class creates unnecessary complexity Mechanics:

1. Create accessor for delegate object
2. Replace each client call to delegating method with call to delegate
3. Delete delegating method after each replacement and test
4. Consider partial removal if only some methods are middle men Eliminates: Middle Man Risk Level: Low

2.7 Introduce Foreign Method

Problem: Utility class lacks needed method you can't add Solution: Create method in client class with utility object parameter When to Use: Can't modify third-party library, temporary workaround Mechanics:

1. Create method in client class taking server class instance as parameter
2. Add server object as first parameter to new method
3. Extract code that uses server object into this method
4. Comment method as "foreign method, should be on server class" Benefits: Reduces repetition, provides field access Risk Level: Low

2.8 Introduce Local Extension

Problem: Utility class lacks multiple needed methods Solution: Create extension class (subclass or wrapper) with new methods When to Use: Cannot modify original, need comprehensive functionality Approaches: Subclass extension or wrapper extension Mechanics:

1. Create extension class as subclass or wrapper of original
2. Add constructors that match all constructors of original
3. Add new features to extension class
4. Replace original class usage with extension class
5. Move any foreign methods into extension class Risk Level: Medium

---

3. ORGANIZING DATA

3.1 Self Encapsulate Field

Problem: Direct access to private fields inside class Solution: Create getter/setter methods, use only these for access When to Use: Want operations during field access, enable lazy initialization Mechanics:

1. Create getting and setting methods for field
2. Find all references to field and replace with getting/setting methods
3. Make field private
4. Test after each group of replacements Benefits: Flexible indirect access, complex operations during access Risk Level: Low

3.2 Replace Data Value with Object

Problem: Data field grown beyond simple primitive value Solution: Create new class, place field and behavior in class When to Use: Primitive field became complex, duplicate code across classes Mechanics:

1. Create class for value and add field of original type
2. Add getting method for field and constructor taking original type
3. Change type of field in source class to new class
4. Change getting method in source class to relay to new class
5. Change setting method to create new instance of new class
6. Consider using Change Value to Reference if needed Benefits: Improves relatedness, consolidates data and behaviors Risk Level: Medium

3.3 Change Value to Reference

Problem: Many identical instances need to be replaced with single object Solution: Convert identical objects to single reference object When to Use: Simple value needs changeable data consistently tracked Mechanics:

1. Use Replace Constructor with Factory Method on value class
2. Determine what object is responsible for providing access to new object
3. Modify factory method to return reference object
4. Test after changing each client to use factory Benefits: Object contains current information, changes accessible program-wide Risk Level: Medium

3.4 Change Reference to Value

Problem: Reference object too small/infrequently changed to justify lifecycle management Solution: Transform reference object into value object When to Use: References require inconvenient management, want immutability Mechanics:

1. Check that candidate is unchangeable or can be made unchangeable
2. Create equals method and hash method if needed
3. Consider providing public constructor instead of factory method
4. Test creation and comparison of new value objects Benefits: Promotes immutability, consistent query results Risk Level: Low

3.5 Replace Array with Object

Problem: Array contains various types of data Solution: Replace array with object having separate fields When to Use: Arrays used like "post office boxes", different data types Mechanics:

1. Create class to represent information in array
2. Change array field to object field and create accessing methods
3. Change each access to array to use new object methods
4. When all array accesses replaced, delete array field Eliminates: Primitive Obsession Risk Level: Medium

3.6 Duplicate Observed Data

Problem: Domain data stored in GUI classes Solution: Separate data into domain classes, ensure synchronization When to Use: Enable multiple interface views, avoid tight coupling Mechanics:

1. Hide direct access to GUI component data with methods
2. Create domain class with interface matching GUI accessor methods
3. Implement Observer pattern between GUI and domain classes
4. Use self-encapsulation to ensure data synchronization Benefits: Splits responsibilities, follows SRP, enables parallel development Risk Level: High

3.7 Change Unidirectional Association to Bidirectional

Problem: Two classes need to use each other's features but have only one-way link Solution: Add back-pointer to class that doesn't have it When to Use: Need reverse lookup, optimize frequent queries Mechanics:

1. Add field for reverse pointer and modify methods to update both
2. Determine which class will control association
3. Create helper method in non-controlling class to set association
4. Modify existing modifier methods to use controlling methods Risk Level: Medium

3.8 Change Bidirectional Association to Unidirectional

Problem: Bidirectional association where one direction isn't needed Solution: Remove unnecessary direction of association When to Use: Reduce complexity, remove unneeded dependencies Mechanics:

1. Examine all readers of field to be removed
2. Provide alternative means for clients to get needed object
3. Remove all updates to field and field itself
4. Test after each change to reading code Risk Level: Medium

3.9 Encapsulate Field

Problem: Public field exists Solution: Make field private, create access methods When to Use: Support encapsulation principle, separate data from behaviors Mechanics:

1. Create getting and setting methods for field
2. Find all clients that reference field and change to use access methods
3. Make field private after all clients changed Benefits: Easier maintenance, allows complex operations on access Risk Level: Low

3.10 Encapsulate Collection

Problem: Class contains collection with simple getter/setter Solution: Make getter read-only, create add/delete methods When to Use: Prevent direct collection manipulation, gain control Mechanics:

1. Create add and remove methods for collection
2. Initialize field to empty collection in constructor
3. Find callers of setting method and modify to use add/remove
4. Find users of getting method and change to use specific methods
5. Make getter return read-only view or copy of collection Eliminates: Data Class Risk Level: Medium

3.11 Replace Magic Number with Symbolic Constant

Problem: Code uses number with specific meaning Solution: Replace numeric value with named constant When to Use: Magic numbers make code harder to understand Mechanics:

1. Declare constant with appropriate name and value
2. Find all occurrences of magic number
3. Check that magic number indeed has same meaning as constant
4. Replace magic number with constant Benefits: Live documentation, easier value changes Risk Level: Low

3.12 Replace Type Code with Class

Problem: Field containing type code not used in operator conditions Solution: Create new class to replace primitive type code When to Use: Common in database interactions, lacks type verification Mechanics:

1. Create class for type code with field containing original code
2. Create static variables with instances for each type code
3. Create static factory method that returns appropriate instance
4. Change type of original field to new class
5. Change accessors to use new class Eliminates: Primitive Obsession Risk Level: Medium

3.13 Replace Type Code with Subclasses

Problem: Coded type directly affects program behavior Solution: Create subclasses for each value, extract behaviors When to Use: Type code uses primitive values, control flow code Mechanics:

1. Self-encapsulate type code field if not already done
2. Make constructor of superclass private
3. Create factory method for superclass using switch on type code
4. Create subclass for each type code value
5. Override factory method in each subclass to return correct instance Eliminates: Primitive Obsession Risk Level: High

3.14 Replace Type Code with State/Strategy

Problem: Coded type affects behavior but can't use subclasses Solution: Replace type code with state object When to Use: Cannot use subclasses, need flexible behavior variation Mechanics:

1. Create state class to represent type code
2. Create subclass of state class for each type code
3. Create factory in superstate to return appropriate state subclass
4. Change type code field to state field
5. Delegate type code dependent methods to state object Benefits: Change object state during lifetime, follows Open/Closed Risk Level: High

3.15 Replace Subclass with Fields

Problem: Subclasses differing only in constant-returning methods Solution: Replace with fields in parent class, eliminate subclasses When to Use: Simplify architecture, remove unnecessary subclasses Mechanics:

1. Use Replace Constructor with Factory Method on subclasses
2. Add fields to superclass for variant information
3. Change subclass methods to return superclass field
4. Use Pull Up Method to pull identical methods to superclass
5. Remove subclasses one at a time and test Risk Level: Medium

---

4. SIMPLIFYING CONDITIONAL EXPRESSIONS

4.1 Decompose Conditional

Problem: Complex conditional (if-then/else or switch) Solution: Break complicated parts into separate methods When to Use: Long conditional code, nested conditions Mechanics:

1. Extract condition into separate method with descriptive name
2. Extract then part into separate method
3. Extract else part into separate method if it exists
4. Replace conditional statement with method calls Benefits: Improved readability, descriptive method names Risk Level: Low

4.2 Consolidate Conditional Expression

Problem: Multiple conditionals leading to same result Solution: Combine conditionals into single expression When to Use: Multiple alternating operators, identical actions Mechanics:

1. Check that none of conditionals have side effects
2. Consolidate conditionals using logical operators (and/or)
3. Extract consolidated condition into method with descriptive name
4. Test after each consolidation step Benefits: Eliminates duplicate control flow, improves readability Risk Level: Low

4.3 Consolidate Duplicate Conditional Fragments

Problem: Identical code in all conditional branches Solution: Move duplicated code outside conditional When to Use: Code evolution created duplication Mechanics:

1. Identify code that executes same way regardless of condition
2. If code at beginning, move before conditional
3. If code at end, move after conditional
4. If code in middle, look to move statements before or after
5. Test after moving each statement Eliminates: Duplicate Code Risk Level: Low

4.4 Remove Control Flag

Problem: Boolean variable acting as control flag Solution: Replace with break, continue, return operators When to Use: Outdated control flag patterns Mechanics:

1. Find value of control flag that gets you out of logic
2. Replace assignments of that value with break or continue
3. Replace any remaining use of control flag with extracted condition
4. Test after each replacement Benefits: Simplifies structure, explicit control flow Risk Level: Low

4.5 Replace Nested Conditional with Guard Clauses

Problem: Nested conditionals making execution flow difficult Solution: Isolate special checks into separate clauses before main checks When to Use: Complex nested logic, obscured normal flow Mechanics:

1. Select outermost condition that is guard clause
2. Replace with guard clause that returns if condition true
3. Continue with remaining conditionals until all guards extracted
4. Consolidate guard conditions if they result in same action Benefits: Linear, readable format, clear edge case handling Risk Level: Low

4.6 Replace Conditional with Polymorphism

Problem: Conditional performs various actions depending on object type Solution: Create subclasses, move branches to polymorphic methods When to Use: Conditionals varying by class/interface/field values Mechanics:

1. Use Extract Method on conditional expression and each leg
2. Use Move Method to move conditional to appropriate class
3. Decide whether to keep superclass method abstract or provide default
4. Replace conditional calls with polymorphic method calls
5. Remove conditional logic once all subclasses have implementations Benefits: Tell-Don't-Ask principle, supports Open/Closed Risk Level: High

4.7 Introduce Null Object

Problem: Many null checks because methods return null Solution: Create Null Object class with default behavior When to Use: Repetitive null checks, simplify conditional logic Mechanics:

1. Create null subclass of source class
2. Create isNull method in source class returning false
3. Override isNull in null class to return true
4. Find places that compare variable with null and replace
5. Find places that call methods on result and override in null class Benefits: Eliminates null checks, improves readability Risk Level: Medium

4.8 Introduce Assertion

Problem: Code portion requires certain conditions to be true Solution: Replace assumptions with specific assertion checks When to Use: Make implicit assumptions explicit, provide live documentation Mechanics:

1. Identify condition you believe is always true
2. Add assertion that tests condition
3. Copy assertion to all places where condition should hold
4. Don't overuse assertions; focus on meaningful invariants Benefits: Stop execution before fatal consequences, highlight assumptions Risk Level: Low

---

5. SIMPLIFYING METHOD CALLS

5.1 Rename Method

Problem: Method name doesn't explain what method does Solution: Rename method to better reflect functionality When to Use: Poor initial naming, functionality evolved Mechanics:

1. Create new method with better name
2. Copy body of old method to new method
3. Find all references to old method and change to call new method
4. Delete old method after all references changed
5. Test after changing each group of references Eliminates: Alternative Classes with Different Interfaces, Comments Risk Level: Low

5.2 Add Parameter

Problem: Method doesn't have enough data to perform actions Solution: Create new parameter to pass necessary data When to Use: Need additional information, occasional/changing data Mechanics:

1. Check whether method is polymorphic (could be overridden)
2. Create new method with additional parameter
3. Copy body of original method to new method
4. Find all callers and change them to call new method
5. Delete old method after all callers changed Drawback: Risk of Long Parameter List Risk Level: Low

5.3 Remove Parameter

Problem: Parameter isn't used in method body Solution: Remove unused parameter When to Use: Unnecessary parameters add complexity Mechanics:

1. Check that parameter isn't used in method body
2. Check whether method is polymorphic
3. Create new method without parameter, copying method body
4. Find all callers and change to call new method
5. Delete old method after all callers changed Eliminates: Speculative Generality Risk Level: Low

5.4 Separate Query from Modifier

Problem: Method returns value and changes object state Solution: Split into query method and modifier method When to Use: Implement CQRS, increase predictability Mechanics:

1. Create query method that returns value without side effects
2. Modify original method to call query and return its result
3. Find every call to modifier and replace with separate calls
4. Make original method return void after all callers changed Benefits: Call queries without state changes, increased predictability Risk Level: Medium

5.5 Parameterize Method

Problem: Multiple methods perform similar actions with different internal values Solution: Combine methods by introducing parameter When to Use: Eliminate duplicate code, make code more flexible Mechanics:

1. Create parameterized method taking parameter for variation
2. Extract common algorithm to parameterized method
3. Replace literal values with parameter references
4. Change each original method to call parameterized method
5. Test after changing each method Eliminates: Duplicate Code Risk Level: Medium

5.6 Replace Parameter with Explicit Methods

Problem: Method contains multiple code paths based on parameter value Solution: Create separate methods for each parameter-dependent variant When to Use: Improve readability, simplify method structure Mechanics:

1. Create explicit method for each value of parameter
2. For each explicit method, copy conditional logic for that parameter
3. Find callers and replace with calls to appropriate explicit method
4. Delete original method when no longer called Benefits: Easier to understand purpose, clearer intent Risk Level: Medium

5.7 Preserve Whole Object

Problem: Get several values from object and pass as parameters Solution: Pass entire object instead of individual values When to Use: Centralize data extraction, reduce parameter management Mechanics:

1. Add parameter for whole object to method
2. Remove individual parameters obtained from object
3. Change method body to get values from new parameter
4. Find callers and change to pass whole object instead of values Benefits: Improved readability, increased flexibility Risk Level: Medium

5.8 Replace Parameter with Method Call

Problem: Calling query method and passing results as parameters Solution: Place query call inside method body When to Use: Long parameter lists, simplify method calls Mechanics:

1. Check that parameter value doesn't change during method execution
2. Check whether evaluation of parameter has side effects
3. Replace parameter references with direct method calls
4. Use Remove Parameter to remove parameter entirely
5. Test after each change Benefits: Eliminates unneeded parameters, simplifies calls Risk Level: Low

5.9 Introduce Parameter Object

Problem: Methods contain repeating group of parameters Solution: Replace parameter groups with single parameter object When to Use: Eliminate duplication, consolidate related parameters Mechanics:

1. Create immutable class for parameter group
2. Use Add Parameter to add parameter object to method
3. For each parameter in group, remove parameter and update references
4. Look for behavior that should move into parameter object
5. Consider making parameter object into value object Eliminates: Long Parameter List, Data Clumps, Primitive Obsession Risk Level: Medium

5.10 Remove Setting Method

Problem: Field value should be set only when created Solution: Remove methods that set field after initial creation When to Use: Prevent changes after initialization, enforce immutability Mechanics:

1. Check that setting method is called only in constructor or method called by constructor
2. Make setting method callable only during construction
3. Move calls to setting method into constructor or constructor-called method
4. Delete setting method Benefits: Increases predictability, reduces unexpected changes Risk Level: Low

5.11 Hide Method

Problem: Method isn't used by other classes or only in class hierarchy Solution: Make method private or protected When to Use: Restrict visibility, simplify public interface Mechanics:

1. Check regularly whether method can be made more private
2. Make each method as private as possible
3. Check after each change that method still accessible where needed
4. Test after each visibility change Eliminates: Data Class Risk Level: Low

5.12 Replace Constructor with Factory Method

Problem: Complex constructor doing more than setting parameter values Solution: Create static factory method to replace constructor calls When to Use: Working with type codes, advanced creation strategies Mechanics:

1. Create factory method that calls existing constructor
2. Replace all calls to constructor with calls to factory method
3. Make constructor private if all external calls replaced
4. Test after replacing each group of constructor calls Benefits: Can return subclass objects, descriptive names, return existing objects Risk Level: Medium

5.13 Replace Error Code with Exception

Problem: Method returns special error code to indicate problem Solution: Replace error codes with throwing exceptions When to Use: Eliminate conditional checks, modern error handling Mechanics:

1. Find all callers that check return value for error codes
2. Change method to throw exception instead of returning error code
3. Change all callers to expect exception in try-catch blocks
4. Test after changing each caller Benefits: Eliminates conditional checks, more succinct error handling Risk Level: Medium

5.14 Replace Exception with Test

Problem: Throw exception where simple test would work Solution: Replace exception handling with conditional test When to Use: Exceptions for routine conditions, improve readability Mechanics:

1. Add conditional test that replicates condition causing exception
2. Move code from catch block to conditional
3. Add else clause with original method call
4. Remove try-catch block after ensuring conditional handles all cases Benefits: Improved readability, explicit edge case handling Risk Level: Low

---

6. DEALING WITH GENERALIZATION

6.1 Pull Up Field

Problem: Two classes have same field Solution: Remove field from subclasses, move to superclass When to Use: Subclasses developed separately, eliminate duplication Mechanics:

1. Inspect all uses of candidate fields to ensure same purpose
2. If fields have different names, rename to same name
3. Create field in superclass
4. Remove fields from subclasses
5. Test after each field removal Eliminates: Duplicate Code Risk Level: Low

6.2 Pull Up Method

Problem: Subclasses have methods performing similar work Solution: Make methods identical, move to superclass When to Use: Subclasses developed independently, eliminate duplication Mechanics:

1. Investigate methods to ensure they do same thing
2. If signatures different, change to match desired superclass signature
3. Copy method to superclass
4. Remove methods from subclasses one at a time
5. Test after each removal Eliminates: Duplicate Code Risk Level: Medium

6.3 Pull Up Constructor Body

Problem: Subclasses have constructors with mostly identical code Solution: Create superclass constructor, move common code When to Use: Constructors can't be inherited, common initialization Mechanics:

1. Create constructor in superclass
2. Move common code from beginning of subclass constructors
3. Call superclass constructor from subclass constructors
4. Move common code from end if applicable Benefits: Eliminates duplication, improves organization Risk Level: Medium

6.4 Push Down Field

Problem: Field used only in few subclasses Solution: Move field to specific subclasses where used When to Use: Planned usage didn't materialize, improve coherency Mechanics:

1. Declare field in all subclasses that need it
2. Remove field from superclass
3. Test compilation and execution
4. Remove field from subclasses that don't need it Eliminates: Refused Bequest Risk Level: Low

6.5 Push Down Method

Problem: Behavior in superclass used by only one subclass Solution: Move method from superclass to relevant subclass When to Use: Method intended universal but used in one subclass Mechanics:

1. Declare method in all subclasses where relevant
2. Copy method body from superclass to subclasses
3. Remove method from superclass
4. Test compilation and execution
5. Remove method from subclasses where not needed Eliminates: Refused Bequest Risk Level: Medium

6.6 Extract Subclass

Problem: Class has features used only in certain cases Solution: Create subclass to handle specific use cases When to Use: Main class has rare use case methods/fields Mechanics:

1. Create subclass of source class
2. Provide constructors for subclass
3. Find all calls to constructors of source class
4. Replace with subclass constructor where appropriate
5. Use Push Down Method and Push Down Field to move features Eliminates: Large Class Risk Level: Medium

6.7 Extract Superclass

Problem: Two classes with common fields and methods Solution: Create shared superclass, move identical functionality When to Use: Code duplication in similar classes Mechanics:

1. Create abstract superclass
2. Make original classes subclasses of superclass
3. Use Pull Up Field, Pull Up Method, Pull Up Constructor Body
4. Examine methods left in subclasses for further extraction opportunities
5. Remove original classes if they become empty Benefits: Eliminates duplication, centralizes common functionality Risk Level: Medium

6.8 Extract Interface

Problem: Multiple clients using same part of class interface Solution: Move common interface portion to dedicated interface When to Use: Indicate special roles, prepare for server type flexibility Mechanics:

1. Create empty interface
2. Declare all common operations in interface
3. Make relevant classes implement interface
4. Adjust client type declarations to use interface Benefits: Isolates common interfaces, explicit role definition Risk Level: Low

6.9 Collapse Hierarchy

Problem: Subclass practically same as superclass Solution: Merge subclass and superclass into single class When to Use: Classes became nearly identical, reduce complexity Mechanics:

1. Choose which class to remove (usually subclass)
2. Use Pull Up Field and Pull Up Method to move features to remaining class
3. Adjust references to removed class to point to remaining class
4. Remove empty class
5. Test after each feature move Benefits: Reduces complexity, fewer classes, easier navigation Risk Level: Medium

6.10 Form Template Method

Problem: Subclasses implement algorithms with similar steps in same order Solution: Move algorithm structure to superclass, leave different implementations in subclasses When to Use: Prevent code duplication, enable parallel development Mechanics:

1. Decompose methods to identify varying and invariant parts
2. Use Extract Method to extract invariant parts with same signature
3. Use Pull Up Method to pull identical methods to superclass
4. For varying methods, declare abstract methods in superclass
5. Replace original algorithm with template method calling extracted methods Eliminates: Duplicate Code Risk Level: High

6.11 Replace Inheritance with Delegation

Problem: Subclass uses only portion of superclass methods Solution: Create field containing superclass object, delegate methods When to Use: Violates Liskov substitution, prevent unintended calls Mechanics:

1. Create field in subclass that refers to instance of superclass
2. Change methods to delegate to superclass field
3. Remove inheritance link
4. Provide methods to access delegate if clients need them Benefits: Eliminates unnecessary methods, enables Strategy pattern Risk Level: High

6.12 Replace Delegation with Inheritance

Problem: Class contains many simple methods delegating to another class Solution: Transform class into subclass of delegate class When to Use: Delegation becomes complex, delegating to all public methods Mechanics:

1. Make delegating class subclass of delegate
2. Remove delegate field and delegating methods
3. Replace all delegate field references with calls to superclass
4. Test after removing each group of delegating methods Benefits: Reduces code length, eliminates redundant methods Risk Level: Medium

Risk Assessment Guidelines

For each refactoring, evaluate:

Low Risk Refactorings

• Rename Method, Extract Variable, Replace Magic Number with Symbolic Constant
• Mitigation: Automated IDE support, compile-time verification

Medium Risk Refactorings

• Extract Method, Move Method, Extract Class
• Mitigation: Comprehensive test coverage, incremental changes

High Risk Refactorings

• Replace Conditional with Polymorphism, Replace Inheritance with Delegation
• Mitigation: Thorough planning, extensive testing, rollback strategy

Language-Specific Considerations

• Java: Consider checked exceptions when moving methods
• Python: Watch for dynamic typing implications
• JavaScript: Be careful with 'this' context when moving methods
• C#: Consider nullable reference types and async/await patterns

Complexity Assessment for Refactoring

Provide realistic complexity assessments:

Simple Refactorings

• Rename Method, Extract Variable, Replace Magic Number
• Remove Parameter, Inline Method

Moderate Refactorings

• Extract Method, Move Method, Extract Class
• Replace Conditional with Polymorphism

Complex Refactorings

• Replace Type Code with State/Strategy
• Replace Inheritance with Delegation
• Duplicate Observed Data

Complexity Factors

• Legacy Code without Tests: Significantly increases complexity
• High Coupling: Moderate complexity increase
• Multiple Inheritance: High complexity increase
• Complex Business Logic: Moderate complexity increase

Always base your recommendations on established refactoring principles from refactoring.guru and ensure each suggestion includes clear rationale, implementation guidance, and expected outcomes. Be specific about which refactoring patterns to use and why they address the particular code smells identified.