设计模式与重构有什么关系？

Question

设计模式与重构有什么关系？

Accepted Answer

设计模式通常**通过重构而产生**，而不是事先设计的——随着代码的增长和需求变得清晰，向模式重构改进了设计。这反映了一个原则：仅在实际需要时应用模式，而不是投机地应用。

## 模式通过重构而产生

```text
Rather than designing patterns in UPFRONT (often premature/speculative), patterns often
emerge as you REFACTOR existing code:
  → start SIMPLE → as needs become clear (real complexity, real duplication, real change
    points), REFACTOR toward a pattern that addresses them
  → "refactor TO a pattern" when the code would genuinely benefit
→ patterns as a destination of refactoring, not a starting blueprint
```

## 重构到模式的示例

```text
→ A growing if/else or switch on "type" → refactor to STRATEGY or polymorphism
→ Duplicated object creation logic → extract a FACTORY
→ A class doing too much (God object) → split responsibilities (toward SRP; extract classes)
→ Hardcoded dependencies (hard to test) → introduce DEPENDENCY INJECTION
→ Complex subsystem usage scattered around → introduce a FACADE
→ Adding behavior via subclass explosion → refactor to DECORATOR (composition)
```

## 为什么这种方法很好

```text
✓ Avoids PREMATURE / speculative patterns (YAGNI) → add the pattern when the need is REAL
✓ The pattern is JUSTIFIED → you've seen the actual problem it solves
✓ Lets design EVOLVE → start simple, add structure as complexity warrants
✓ Refactoring is SAFE with tests → tests let you refactor toward patterns confidently
→ "make it work, make it right (refactor, possibly to patterns), make it fast"
```

## 为什么这很重要

理解模式与重构的关系是宝贵的高级知识，因为它反映了**在实际需要时应用模式**（通过重构）而不是投机的**成熟方法**，因此它指导我们更好地使用模式。

关键见解是设计模式通常**通过重构而产生**，而不是事先设计的——从简单开始，当真实需求（复杂性、重复、变更点）变得清晰时，向模式重构。

这种"重构到模式"的方法将模式视为重构的目标，而不是起始蓝图，这是一种更成熟、风险更低的应用方法。

理解**示例**——将不断增长的条件重构为 Strategy，将重复的创建逻辑提取为 Factory，将 God 对象分解为单一职责，为硬编码依赖引入依赖注入，为分散的子系统使用添加 Facade，以及将子类爆炸重构为 Decorator——说明了当模式所解决的问题实际出现时，真实代码如何向模式演变。

理解**为什么这种方法很好**是关键价值：它**避免了过早/投机的模式**（YAGNI——仅在需求真实时添加模式，而不是猜测未来需求和过度设计），确保模式是**合理的**（你已经看到了实际问题），让**设计演变**（从简单开始，根据复杂性增加结构），并且**对测试是安全的**（测试使自信地重构成为可能）。

这与更广泛的智慧相关：