--- name: refactoring-catalog description: "Code refactoring catalog. An extension skill for architecture-reviewer/performance-analyst that provides Martin Fowler-based refactoring patterns, code smell detection-to-refactoring mapping, SOLID principle violation identification, and complexity measurement criteria. Use when reviewing code structure improvement involving 'refactoring', 'code smells', 'SOLID violations', 'complexity', 'design patterns', 'code quality', etc. Note: direct code modification and security analysis are outside the scope of this skill." --- # Refactoring Catalog — Code Refactoring Catalog A reference of code smell-to-refactoring mappings, SOLID violation identification, and complexity metrics used by the architecture-reviewer and performance-analyst agents during code structure analysis. ## Target Agents - `architecture-reviewer` — Applied when suggesting refactoring based on design patterns and SOLID principles - `performance-analyst` — Applied when suggesting refactoring related to complexity analysis and performance ## Code Smell to Refactoring Mapping ### Size-Related Smells | Code Smell | Symptoms | Refactoring Technique | |-----------|----------|----------------------| | **Long Method** | 20+ lines | Extract Method, Replace Temp with Query | | **Large Class** | 300+ lines or 10+ fields | Extract Class, Extract Subclass | | **Long Parameter List** | 4+ parameters | Introduce Parameter Object, Builder Pattern | | **Data Clumps** | Same field groups repeated | Extract Class | | **Primitive Obsession** | Domain concepts as primitives | Value Object, Enum | ### Structure-Related Smells | Code Smell | Symptoms | Refactoring Technique | |-----------|----------|----------------------| | **Feature Envy** | Excessive use of another class's data | Move Method | | **Data Class** | Class with only getters/setters | Move behavior into class | | **Shotgun Surgery** | One change affects multiple classes | Move Method/Field, Inline Class | | **Divergent Change** | One class changes for multiple reasons | Extract Class (SRP) | | **Duplicated Code** | Identical/similar code repeated | Extract Method, Template Method | | **Middle Man** | Class that only delegates | Remove Middle Man, Inline Class | | **Inappropriate Intimacy** | Excessive coupling between classes | Move Method/Field, Extract Class | | **Switch/If Chain** | Long conditional branching | Replace Conditional with Polymorphism, Strategy | | **Refused Bequest** | Inherited but unused methods | Replace Inheritance with Delegation | | **Comments** | Complex logic explained by comments | Extract Method (self-documenting code) | ## SOLID Principle Violation Identification ### S — Single Responsibility Principle | Violation Signal | Identification Criteria | Refactoring | |-----------------|------------------------|-------------| | Class name contains "And", "Manager" | Implies multiple responsibilities | Extract Class | | 2+ reasons to change | "If X changes this class changes, and if Y changes this class also changes" | Separate classes by responsibility | | Highly diverse imports | Imports DB, HTTP, UI, logging all together | Layer separation | ### O — Open/Closed Principle | Violation Signal | Identification Criteria | Refactoring | |-----------------|------------------------|-------------| | Switch/if modified when adding new types | Existing code modification required | Strategy Pattern, Polymorphism | | Hardcoded branching | Code added for each new condition | Plugin/Registry pattern | ### L — Liskov Substitution Principle | Violation Signal | Identification Criteria | Refactoring | |-----------------|------------------------|-------------| | Override throws exception in child class | `NotImplementedError`, `UnsupportedOperationException` | Interface segregation, Inheritance to Composition | | Type checking then casting | `instanceof` / `typeof` branching | Redesign with polymorphism | ### I — Interface Segregation Principle | Violation Signal | Identification Criteria | Refactoring | |-----------------|------------------------|-------------| | Empty interface implementations | `pass`, `{}`, `noop` | Interface segregation | | "Fat" interface | 10+ methods | Split into Role Interfaces | ### D — Dependency Inversion Principle | Violation Signal | Identification Criteria | Refactoring | |-----------------|------------------------|-------------| | Direct concrete class instantiation | Hardcoded `new ConcreteService()` | Dependency Injection | | Upper module imports lower module | Business logic directly uses DB library | Interface/Port abstraction | ## Complexity Measurement Criteria ### Cyclomatic Complexity Branch points (if/else/switch/for/while/catch) + 1 | Score | Complexity | Action | |-------|-----------|--------| | 1-5 | Low | Appropriate | | 6-10 | Medium | Review with care | | 11-20 | High | Refactoring recommended | | 21+ | Very high | Refactoring required | ### Cognitive Complexity Difficulty of human code comprehension. Weight increases with deeper nesting. | Element | Base Increment | Nesting Bonus | |---------|---------------|---------------| | if/else/switch | +1 | +nesting level | | for/while/do | +1 | +nesting level | | catch | +1 | +nesting level | | break/continue to label | +1 | - | | Logical operator chain (&&, ||) | +1 | - | | Recursive call | +1 | - | ### Recommended Thresholds | Metric | Method/Function | Class/File | |--------|----------------|-----------| | Lines of code | Under 20 | Under 300 | | Cyclomatic complexity | 10 or less | - | | Cognitive complexity | 15 or less | - | | Parameter count | 4 or less | - | | Nesting depth | 3 levels or less | - | | Dependency count | - | 10 or less | ## Design Pattern Application Guide ### Smell to Pattern Mapping | Problem Situation | Applicable Pattern | Effect | |------------------|-------------------|--------| | Behavioral branching via conditionals | **Strategy** | OCP compliance, easy to add new behaviors | | Complex object creation logic | **Factory Method/Builder** | Encapsulate creation logic | | Same algorithm skeleton, different details | **Template Method** | Remove duplication, isolate change points | | Behavior changes based on state | **State** | Remove conditionals, clarify state transitions | | Event propagation to multiple objects | **Observer** | Loose coupling | | Integrating incompatible interfaces | **Adapter** | Integration without modifying existing code | | Simplifying complex subsystems | **Facade** | Interface simplification | | Dynamically adding features to objects | **Decorator** | Feature extension without inheritance | ## Refactoring Priority Decision ### Impact-Difficulty Matrix | | Low Difficulty | High Difficulty | |--|---------------|----------------| | **High Impact** | Do immediately | Plan then execute | | **Low Impact** | When time allows | Defer (low cost-benefit) | ### Refactoring Suggestion Format ``` [Severity] Code Smell: [Smell Name] Location: [File:Line] Current State: [Problem description] Refactoring: [Technique name] Expected Effect: [How it improves] Estimated Difficulty: [Low/Medium/High] ```