refactoring-to-patternslisted

# Refactoring to Patterns Change internal structure without changing observable behavior. Every step leaves all tests passing. **Never refactor while also adding features** — separate the two activities into separate commits. ## When to refactor - **Before making a change that the current structure makes hard.** Two small moves beat one large dangerous move. - **On the third duplication.** Rule of Three: tolerate it the second time. - **Before debugging code you cannot understand.** Clarify, then fix. Do **not** refactor when tests are failing (fix them first), when the code works and no change is imminent, or when a deadline is live — note the smell and move on. ## Smell → refactoring | Smell | Reach for | |-------|-----------| | Long Method | Extract Method; Replace Temp with Query; Decompose Conditional | | Duplicate Code | Extract Method; Extract Class; Pull Up Method; Form Template Method | | Large Class | Extract Class; Extract Subclass; Extract Interface | | Long Parameter List | Introduce Parameter Object; Preserve Whole Object | | Divergent Change (one class, several reasons to change) | Extract Class along each reason | | Shotgun Surgery (one change, many classes) | Move Method / Move Field; Inline Class | | Feature Envy (method more interested in another class's data) | Move Method | | Primitive Obsession | Replace Data Value with Object; Replace Type Code with Class or Subclasses | | Conditional Complexity | Replace Conditional with Polymorphism; Introduce