Refactoring patterns, techniques, and decision frameworks. Use when improving existing code structure, reducing complexity, eliminating code smells, choosing between refactoring approaches, or deciding when refactoring is worthwhile. Covers extraction, encapsulation, type-based refactoring, strategy patterns, modularity improvements, and compiler-guided transformation.
| Pattern | What It Does | When to Use | Risk |
|---|---|---|---|
| Extract Method | Break long function into named steps | Function exceeds 5-7 lines or mixes abstraction levels | Low |
| Inline Method | Remove unnecessary indirection | Method adds no clarity; just delegates | Low |
| Replace Type Code with Classes | Turn enums/constants into class hierarchies | if/else or switch on type codes | Medium |
| Push Code into Classes | Move logic from callers into the class it belongs to | Logic about a class lives outside it | Medium |
| Specialize Method | Create focused versions of overly general methods | Method has parameters used only in some call sites | Low |
| Delete code and let the compiler verify safety |
| Suspected dead code, unused parameters |
| Low |
| Unify Similar Classes | Merge classes that differ only in constants | Near-duplicate classes with identical structure | Medium |
| Combine Ifs | Merge consecutive ifs with identical bodies | Repeated conditional blocks | Low |
| Introduce Strategy Pattern | Extract varying behavior into strategy objects | Multiple classes share structure but differ in behavior | High |
| Extract Interface | Create interface from existing implementation | Need to decouple consumers from concrete class | Medium |
| Eliminate Getter/Setter | Move behavior to where the data lives | External code pulls data, operates, pushes back | Medium |
| Encapsulate Data | Wrap related variables in a class | Loose variables travel together across functions | Medium |
| Enforce Sequence | Use constructors to guarantee operation ordering | Methods must be called in a specific order | Medium |
Is there a concrete problem?
├── No → Don't refactor. "If it ain't broke, don't fix it."
└── Yes → What kind of problem?
├── Hard to understand → Extract Method, rename, Encapsulate Data
├── Hard to change → Push Code into Classes, Extract Interface
├── Duplicated logic → Unify Similar Classes, Introduce Strategy
├── Scattered conditionals → Replace Type Code with Classes
├── Wrong abstraction level → Inline Method, Specialize Method
└── Dead or unused code → Try Delete Then Compile
| Smell | Signal | Refactoring Response |
|---|---|---|
| Long method | Function exceeds 5-7 lines of logic | Extract Method |
| Mixed abstraction levels | Function both calls methods and does low-level work | Extract Method |
| Deep nesting | Conditionals nested 3+ levels | Extract Method, guard clauses |
| if/else chains | Type-checking with if/else on enums | Replace Type Code with Classes |
| Getters and setters | External code pulls data, transforms, pushes back | Eliminate Getter/Setter |
| Common prefixes/suffixes | Multiple functions share a prefix like player_* | Encapsulate Data |
| Primitive obsession | Related primitives passed together | Encapsulate Data |
| Smell | Signal | Refactoring Response |
|---|---|---|
| Hard-coded dependencies | Constructor creates its own collaborators | Inject dependencies through constructor |
| Concrete class coupling | Code depends on implementation, not interface | Extract Interface |
| Feature envy | Method uses another class's data more than its own | Push Code into Classes |
| Leaking implementation details | Return types expose internal layers | Wrap in domain-appropriate types |
| Global state | Shared mutable state makes code unsafe | Inject shared state as explicit dependency |
Push invariants as high up this hierarchy as possible. Levels 1-2 are dramatically more reliable than 3-6.
| Level | Mechanism | Reliability |
|---|---|---|
| 1. Eliminate the invariant | Redesign so the problem can't occur | Highest |
| 2. Compiler-enforced | Type system prevents violations | High |
| 3. Runtime-enforced | Assertions, guards, validation | Medium |
| 4. Documented | Comments, README, wiki | Low |
| 5. Verbal | Told during onboarding | Very low |
| 6. Hoped for | Undocumented assumption | None |
| You're struggling with... | Primary Pattern | Supporting Pattern |
|---|---|---|
| Function too long to understand | Extract Method | Specialize Method |
| if/else chains on type codes | Replace Type Code with Classes | Push Code into Classes |
| Changing one thing breaks another | Extract Interface | Dependency injection |
| Duplicated code across classes | Unify Similar Classes | Introduce Strategy Pattern |
| Data exposed through getters | Eliminate Getter/Setter | Push Code into Classes |
| Related variables scattered | Encapsulate Data | Enforce Sequence |
| Suspected dead code | Try Delete Then Compile | — |
| Methods must be called in order | Enforce Sequence | Encapsulate Data |
| Deep inheritance tree | Extract Interface + composition | Introduce Strategy Pattern |
Before:
During:
After: