Refactoring Patterns

Comprehensive refactoring guide based on Martin Fowler’s “Refactoring: Improving the Design of Existing Code.”

Core Principle

Small Change → Test → Commit → Repeat

Every refactoring must preserve existing behavior while improving code structure.

The Refactoring Cycle

1. Identify One Small, Isolated Change

   • Extract a single method/function
   • Rename one variable for clarity
   • Eliminate one piece of duplication
   • Simplify one conditional
   • ONE change at a time (< 10 lines affected)

2. Make the Change

   • Preserve existing behavior (no new features)
   • Keep scope minimal

3. Run All Tests Immediately

   • ✅ Green? → Proceed to step 4
   • ❌ Red? → Revert immediately, try smaller change

4. Commit the Change

   • Descriptive message: “Refactor: extract calculateDiscount method”
   • Creates safety checkpoint for rollback

5. Repeat – Build on the previous improvement

Safety Rules (Non-Negotiable)

• NEVER refactor without passing tests
• NEVER combine refactoring with new features
• NEVER make “just one more small change” without testing
• ALWAYS commit after each successful step
• ALWAYS have a working state to revert to
• Maximum 15 minutes per refactoring step (break down if longer)

Red-Green-Refactor Discipline

RED    → Write failing test for new feature
GREEN  → Minimal code to pass test (can be ugly)
REFACTOR → Improve code in tiny increments (test after each)
         → ONLY when all tests are green
         → Commit after each improvement

Refactoring Catalog

Composing Methods

Extract Method – Create well-named method from code fragment

• Use when: Semantically dense code, different abstraction levels, replacing comments
• Don’t use if: Cannot give a better name than current method
• Steps: Copy block → create method → test → replace with call → test → rename → test

Inline Method – Replace method call with method body

• Use when: Needless indirection, preparing for larger refactoring
• Don’t use if: Subclass overrides the method

Inline Temp – Replace temp variable with direct method call

• Use when: Temp assigned from method call only once
• Often leads to: Replace Temp with Query

Replace Temp with Query – Extract expression to method, remove temp

• Use when: Expression used once, temp assigned once
• Benefit: Reduces method size, enables reuse

Introduce Explaining Variable – Put complex expression in temp with clear name

• Use when: Complex conditionals need clarity
• Alternative: Prefer Extract Method for recurring checks

Split Temporary Variable – Create separate temp for each assignment

• Use when: Temp reused for different purposes (not loop/accumulator)
• Identifies: Variables named temp, foo, x (poor names)

Remove Assignments to Parameters – Use temp instead of assigning to parameter

• Avoids: Confusion between pass-by-value and pass-by-reference
• Exception: Output parameters (use sparingly)

Replace Method with Method Object – Turn method into its own class

• Introduces: Command Pattern
• Use when: Long method with local variables preventing Extract Method

Substitute Algorithm – Replace algorithm with clearer/simpler one

• Select based on: Performance, succinctness, expressiveness
• Must have tests before substituting

Moving Features Between Objects

Move Method – Move method to class that uses it most

• Use when: Method uses more features of another class

Move Field – Move field to class that uses it most

Extract Class – Create new class for subset of responsibilities

• Use when: Class doing work of two classes

Inline Class – Merge class into another when it’s no longer pulling weight

Hide Delegate – Create method to hide delegation

• Encapsulates: Knowledge of other objects

Remove Middle Man – Call delegate directly when middle man is thin wrapper

Organizing Data

Replace Magic Number with Symbolic Constant

• Turn literal numbers into named constants

Encapsulate Field – Make field private, provide accessors

Encapsulate Collection – Return read-only view, provide add/remove methods

Replace Type Code with Class – Replace integer codes with class

• Alternative: Use enums or type-safe enums

Replace Type Code with Subclasses – Turn codes into inheritance

• Use when: Behavior varies by type code

Replace Type Code with State/Strategy – Use State/Strategy pattern

• Use when: Type code changes during lifetime, or can’t use subclasses

Simplifying Conditional Expressions

Decompose Conditional – Extract condition and branches into methods

• Example: if (date.before(SUMMER_START)) → if (notSummer(date))

Consolidate Conditional Expression – Combine conditions with same result

• Use logical operators to unify checks

Consolidate Duplicate Conditional Fragments – Move identical code outside conditional

Remove Control Flag – Use break, continue, or return instead of flag variable

Replace Nested Conditional with Guard Clauses – Use early returns

• Example: if (!valid) return; // rest of method

Replace Conditional with Polymorphism – Move conditional to subclass methods

Introduce Null Object – Replace null checks with null object

• Null object implements interface with do-nothing methods

Introduce Assertion – Make assumptions explicit

• Example: assert(balance >= 0, "Balance cannot be negative")

Making Method Calls Simpler

Rename Method – Make name explain purpose

Add Parameter / Remove Parameter – Adjust parameter list

Separate Query from Modifier – Split methods that return value and change state

Parameterize Method – Use parameter instead of multiple similar methods

Replace Parameter with Explicit Methods – Create separate method for each value

Preserve Whole Object – Pass entire object instead of multiple values

Replace Parameter with Method – Remove parameter by calling method

Introduce Parameter Object – Group parameters into object

Remove Setting Method – Make field immutable after construction

Hide Method – Make method private if not used outside class

Replace Constructor with Factory Method – Return polymorphic type

Replace Error Code with Exception – Throw exception instead of returning code

Replace Exception with Test – Check condition first to avoid exception

Dealing with Generalization

Pull Up Field / Pull Up Method – Move to superclass when identical in subclasses

Push Down Field / Push Down Method – Move to subclass when used only there

Extract Subclass – Create subclass for features used in some instances

Extract Superclass – Create superclass for common features

Extract Interface – Create interface when classes share subset of features

Collapse Hierarchy – Merge subclass into superclass when too similar

Form Template Method – Move invariant steps to superclass, override variants

Replace Inheritance with Delegation – Use composition when subclass uses only part of superclass

Replace Delegation with Inheritance – Make delegate a subclass if using all features

Example: Incremental Application

Bad Approach (risky – batched changes):

// Extract 3 methods + rename 5 variables + reorganize imports
// Run tests → many failures → hard to debug

Good Approach (safe – incremental):

1. Extract calculateSubtotal() → test → commit
2. Extract calculateTax() → test → commit  
3. Extract calculateTotal() → test → commit
4. Rename 'amt' to 'amount' → test → commit
5. Rename 'calc' to 'calculate' → test → commit

References

Based on Martin Fowler’s “Refactoring: Improving the Design of Existing Code”

• https://refactoring.com/catalog/