Design Pattern Analysis and Refactoring

Problem

A lot of code fails not because it throws errors, but because its structure degrades as requirements grow: if-else and switch branches keep expanding, classes grow beyond 300 lines, constructors accumulate parameters, high-level modules directly instantiate concrete classes, interfaces carry unrelated methods, and multiple systems maintain duplicated logic. These issues usually stay quiet until the next change becomes expensive: adjusting one payment branch affects order flow, adding an export format rewrites the report class, or adapting to a legacy interface forces compatibility logic into business code. Design patterns are not decorative vocabulary; they make variation points, object creation, behavior switching, and object collaboration explicit.

How It Works

The skill turns code review into a concrete workflow: detect common code smells, check SRP, OCP, LSP, ISP, and DIP, match the problem to a GoF pattern, and output refactor suggestions tied to the specific issue. It handles typical cases such as replacing conditional object creation with factory methods or abstract factories, using Builder for complex construction, converging runtime behavior switching with Strategy or State, and distinguishing Adapter, Decorator, and Proxy. For easily confused patterns, it gives boundaries: strategy is client-driven algorithm switching, while state is behavior driven by state transitions; template method relies on inheritance and fixes the skeleton at compile time, whereas strategy relies on composition and supports runtime replacement.

Scope

This skill is best for existing code whose structure is becoming hard to maintain, such as branch-heavy logic, mixed responsibilities, tight object creation coupling, or scattered event handling. It is not a license to over-engineer simple code: do not introduce factories where constructors are enough, and do not force abstractions where a plain method would work. Refactoring should preserve backward compatibility, isolate the parts most likely to change, and address one principle violation at a time instead of redrawing the entire system.