设计原则——开放封闭原则（Open Close Principle）

定义

开闭原则是对系统在面对变化时所表现的特征的描述：对于扩展是开放的（Open for extension），而对于修改是封闭的（Closed for modification）1。它是一种现象的描述，所以可能改叫开闭特征（Open Close Characteristics）更恰当些。

原因

任何系统在其生命周期都会发生变化。如果系统中的一处改动产生了连锁反应，导致一系列相关模块的改动，那么设计就具有僵化性（Rigidity）2的臭味。OCP建议我们对系统进行重构，设计一种抽象隔离这种变化，这样以后再进行同样的改动时，就只需要添加新的代码，而不必改动已经正常运行的代码。

关键是抽象

实现开闭特征的关键是抽象.比如遵循依赖倒置原则（DIP）：
+ 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。
+ 抽象不应该依赖于细节。细节应该依赖于抽象。

上图展示了策略模式（Strategy Method）。Client需要实现一些功能，它可以用Client Interface去描绘那些功能，Client Interface的子类型可以以任何它们所选择的方式去实现这个接口。这样，就可以通过创建Client Interface的新的子类型的方式去扩展、更改Client中指定的行为。这种模式遵循了依赖倒置原则，实现了开闭特征。

隔离变化

一般而言，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化，没有对于所有情况都贴切的模型。如果我们预测到了一种变化，就应该设计一种抽象来隔离它。

• 只受一次愚弄
  为了防止出现不必要的复杂性的臭味，我们会允许自己被愚弄一次。这意味着在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发送的同类变化。简而言之，我们愿意被第一颗子弹击中，然后我们就会确保自己不再被同一只枪发射的其它任何子弹击中。

• 刺激变化
  如果我们愿意接受第一颗子弹，那么子弹来到越早、越快就对我们越有利。因此我们需要刺激变化。

  • 测试驱动。一个可测试的系统通常已经建立了隔离许多变化的抽象。
  • 缩短迭代周期。——一个周期为几天而不是几周。
  • 在加入基础结构前就开发特性。持续将那些特性展示给涉众。
  • 首先开发最重要的特性。
  • 持续集成。

结论

满足开闭特性的系统可以带来OOP所声称的巨大好处（灵活性、可重用性以及可维护性）。然而，对于系统的每个部分都肆意地进行抽象同样不是个好主意。正确的做法是，应该仅对系统中呈现频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身同样重要。

---

1. 《敏捷软件开发：原则、模式与实践》 ↩
2. 僵化性（Rigidity）:很难对系统进行改动，因为每个改动都会迫使许多对系统其它部分的改动。 ↩