| name | refactor |
| description | | Use when this capability is needed. |
Refactoring Catalog (Multi-Language)
A comprehensive, technique-by-technique catalog of refactoring best practices for any language, sourced from Martin Fowler's Refactoring: Improving the Design of Existing Code (2nd Edition) and Alexander Shvets' Refactoring in Java (Refactoring Guru). Adapted for Python, TypeScript, Go, and Rust with idiomatic examples.
Step 0: Detect Language
Before applying any technique, detect the project's stack:
| Project File | Language | Idiom Style |
|---|
pom.xml / build.gradle | Java | OOP, Stream API |
pyproject.toml / requirements.txt / setup.py | Python | Duck typing, comprehensions |
package.json + tsconfig.json | TypeScript | Functional-OOP hybrid |
package.json (no tsconfig) | JavaScript | Prototype-based, functional |
*.csproj | C# | OOP, LINQ |
go.mod | Go | Composition, implicit interfaces |
build.gradle.kts | Kotlin | OOP + functional |
Gemfile | Ruby | Duck typing, open classes |
composer.json | PHP | OOP |
Cargo.toml | Rust | Ownership, traits, no inheritance |
Package.swift | Swift | Protocol-oriented |
If the language is Java, apply techniques with Java OOP, Stream API where appropriate, and the project's detected Java version constraints.
Language Support Matrix
| Concept | Python | TypeScript | Go | Rust |
|---|
| Class / struct | class | class | struct + methods | struct + impl |
| Inheritance | class Child(Parent) | extends | Embedding (no inheritance) | Traits (no inheritance) |
| Interface / contract | Protocol / ABC | interface | interface (implicit) | trait |
| Encapsulation | _private convention | private keyword | Unexported (lowercase) | Private by default, pub |
| Polymorphism | Duck typing + ABC | Interfaces + classes | Implicit interfaces | Trait objects + generics |
| Generics | typing.Generic[T] | <T> | [T any] | <T: Trait> |
| Error handling | Exceptions | Exceptions | Error values (error) | Result<T, E> |
| Null safety | None / Optional[T] | null / undefined / ? | nil (zero values) | Option<T> |
| Collections pipeline | Comprehensions / generators | Array methods (.map, .filter) | for range (no pipeline) | Iterator chain (.filter().map()) |
| Pattern matching | match (3.10+) | switch (no pattern matching) | switch (no pattern matching) |
For detailed concept-to-language mappings, see references/language-idioms.md.
Core Philosophy
Refactoring is the process of changing the internal structure of code without altering its observable behavior. It is a disciplined technique, not a random cleanup. The golden rule is: Cover → Modify → Refactor (always have tests before you start).
How to Use This Skill
- Detect the language (Step 0 above)
- Diagnose first: Identify the code smell (see
techniques/00-code-smells-diagnostic.md)
- Check applicability: See
references/language-applicability.md for technique availability per language
- Select technique: Each smell maps to one or more refactoring techniques
- Read the technique file: Each technique has multi-language examples (Python, TypeScript, Go, Rust)
- For Java: Use Java OOP/Stream idioms and honor Java 8 versus Java 11+ API availability
- For language idiom mapping: See
references/language-idioms.md
- Apply incrementally: Small steps, test after each change, commit frequently
Technique Categories
The techniques are organized in 7 groups. Each technique has its own file in the techniques/ directory.
Group 1: Composing Methods (techniques/01-XX)
Techniques for building clean, well-structured methods. The foundation of all refactoring.
01-extract-method.md — Extract a code fragment into a named function
02-inline-method.md — Replace a function call with the function body
03-extract-variable.md — Give a name to a complex expression
04-inline-variable.md — Remove a variable that adds no clarity
05-replace-temp-with-query.md — Replace temp variables with function calls
06-replace-method-with-method-object.md — Turn a complex function into its own class/struct
07-substitute-algorithm.md — Replace an algorithm with a clearer version
Group 2: Moving Features (techniques/02-XX)
Techniques for placing code where it truly belongs.
08-move-method.md — Move a function to where it has more cohesion
09-move-field.md — Move a field to the type that uses it most
10-extract-class.md — Split a type with multiple responsibilities
11-inline-class.md — Merge a type that does too little
12-hide-delegate.md — Encapsulate chain navigation behind a simpler interface
13-remove-middle-man.md — Remove unnecessary delegation
14-move-statements.md — Move statements into/out of functions, slide statements
15-split-loop.md — Separate a loop that does multiple things
16-replace-loop-with-pipeline.md — Use declarative pipelines instead of imperative loops
17-remove-dead-code.md — Delete unused code
Group 3: Organizing Data (techniques/03-XX)
Techniques for enriching data with behavior and protecting internal state.
18-encapsulate-variable.md — Wrap data access with getters/functions
19-encapsulate-record.md — Convert data structures into objects/structs
20-encapsulate-collection.md — Protect collections from external mutation
21-replace-primitive-with-object.md — Create domain types instead of using raw primitives
22-split-variable.md — Give each purpose its own variable
23-rename-field.md — Improve field names for clarity
24-replace-derived-variable-with-query.md — Calculate values on demand
25-change-reference-to-value.md — Make objects immutable (Value Objects)
26-change-value-to-reference.md — Share a single instance across consumers
27-replace-type-code-with-subclasses.md — Convert type codes to polymorphic hierarchy
Group 4: Simplifying Conditionals (techniques/04-XX)
Techniques for taming conditional complexity.
28-decompose-conditional.md — Name condition and branches
29-consolidate-conditional.md — Merge related conditions
30-replace-nested-conditional-with-guard-clauses.md — Early returns for special cases
31-replace-conditional-with-polymorphism.md — Use polymorphism instead of switch/if-type
32-introduce-special-case.md — Null Object pattern for default behavior
33-introduce-assertion.md — Document invariants with executable assertions
34-replace-control-flag.md — Replace boolean flags with break/return
Group 5: Simplifying Method Calls / API Design (techniques/05-XX)
Techniques for building self-documenting interfaces.
35-change-function-declaration.md — Rename functions and change parameters
36-introduce-parameter-object.md — Group related parameters into an object
37-parameterize-function.md — Unify similar functions with a parameter
38-remove-flag-argument.md — Replace boolean params with named functions
39-preserve-whole-object.md — Pass the object instead of extracted values
40-replace-parameter-with-query.md — Let the function calculate what it needs
41-replace-query-with-parameter.md — Pass value as param for purity/testability
42-remove-setting-method.md — Make properties read-only
43-replace-constructor-with-factory.md — Use factory functions for flexible creation
44-replace-function-with-command.md — Encapsulate function as object
45-separate-query-from-modifier.md — CQS: separate reads from writes
Group 6: Dealing with Generalization (techniques/06-XX)
Techniques for refactoring type hierarchies and shared behavior.
46-pull-up-method.md — Move duplicated functions to shared parent/trait/interface
47-push-down-method.md — Move specialized functions to specific types
48-pull-up-constructor-body.md — Unify constructor/initialization logic
49-extract-superclass.md — Create common parent for shared behavior
50-extract-interface.md — Define a contract without implementation
51-collapse-hierarchy.md — Merge unnecessary hierarchy levels
52-form-template-method.md — Template Method pattern
53-replace-subclass-with-delegate.md — Composition over inheritance
54-replace-superclass-with-delegate.md — Replace extends with has-a
55-replace-inheritance-with-delegation.md — General inheritance to delegation
Group 7: Additional Techniques (techniques/07-XX)
Cross-cutting techniques from both sources.
56-combine-functions-into-class.md — Group functions that share data
57-combine-functions-into-transform.md — Enrich read-only data
58-split-phase.md — Separate code into processing phases
59-introduce-foreign-method.md — Extend third-party types you can't modify
60-introduce-local-extension.md — Wrapper or subclass for library extension
61-replace-error-code-with-exception.md — Modernize error handling
62-replace-exception-with-test.md — Don't use exceptions for control flow
Diagnostic Guide
Start with techniques/00-code-smells-diagnostic.md to identify which techniques apply to your code. The diagnostic maps 24 code smells to their recommended refactoring techniques.
Applying the Skill
When given code to refactor:
- Detect the language (Step 0)
- Read
techniques/00-code-smells-diagnostic.md to identify the smells present
- For each identified smell, read the corresponding technique file(s)
- Check
references/language-applicability.md — if the technique doesn't apply to the target language, the table shows the alternative
- Apply techniques in small steps, always testing between changes
- Provide idiomatic examples for the detected language
- Explain WHY each refactoring improves the code, not just HOW to do it
- For language-specific idiom translations, consult
references/language-idioms.md
Key Principles
These principles underpin every technique in the catalog:
- Names matter more than length — a well-named 1-line function is better than an inline expression
- Small steps — extract small fragments, test, commit. Never batch multiple changes
- Intention over implementation — code should communicate WHAT, not HOW
- Data and logic that change together should live together — cohesion is king
- Prefer composition over inheritance — delegation is more flexible than extends
- Immutability is a powerful preservative — immutable data is easier to reason about
- CQS (Command-Query Separation) — a function either returns a value or modifies state, never both
Reference Files
| File | Content |
|---|
references/language-idioms.md | Refactoring concept → {Python, TypeScript, Go, Rust} equivalents |
references/language-applicability.md | 62-technique × language applicability matrix with alternatives |
Source: andresnator/agents-orchestrator — distributed by TomeVault.