software-design-patterns-and-refactoring

# Design Patterns and Refactoring ## Overview This skill captures one practical truth: design-pattern thinking is useful before coding, and refactoring thinking is useful after coding — but both can improve the structure of the system when used with restraint. Its purpose is not to dump a giant catalog of pattern names. Its purpose is to help decide: - when a structural problem exists before coding - which pattern family is worth considering - when code smells indicate refactoring pressure - how to improve structure without turning the code into abstraction theater Core principle: **patterns are design tools, refactoring is structure repair, and both should serve clarity of responsibility rather than decorative cleverness.** ## When to Use Use when: - the team is deciding a class/module collaboration structure before coding - code review reveals repeated structure problems or code smells - a change is easier to express as a structural pattern decision than as ad hoc branching - implementation is becoming hard to extend, test, or reason about - you need one practical bridge between pre-code design and post-code cleanup Do not use when: - the problem is fundamentally domain-boundary or system-architecture design - the task is a trivial code change with no structural pressure - the user only wants pattern definitions without design judgment - the code is so small that introducing indirection would only make it worse ## Two Main Uses ### 1. Before-code structural guidanc...