敏捷软件开发 - 原则、模式与实践 —— 敏捷设计（三）开放-封闭原则

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第9章。

开放-封闭原则 （OCP - The Open/Closed Principle）

软件实体（类、模块、函数等等）应该是可以扩展的，但是不能修改的。
对于扩展是开放的。对于更改是封闭的。

关键是抽象

一般而言，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。没有对于所有的情况都贴切的模型。既然不可能完全封闭，那么就必须有策略的对待这个问题。也就是说，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离这些变化。

我们如何知道哪个变化有可能发生呢？我们进行适当的调查，提出正确的问题，并且使用我们的经验和一般常识。最终，我们会一直等到变化发生时才采取行动。

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

• 刺激变化
  如果我们决定接受第一颗子弹，那么子弹到来的越早、越快就对我们越有利。我们希望在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。因此，我们需要去刺激变化。我们已在前面介绍过一些方法来完成这项工作。

  • 我们首先编写测试。
  • 我们使用很短的迭代周期进行开发
  • 我们在加入基础结构前就可发特性，并且经常性地把那些特性展示给涉众。
  • 我们首先开发最重要的特性。
  • 尽早地、经常性地发布软件。

结论

在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性以及可维护性）。然而，并不是说只要使用一种面向对象语言就是遵循了这个原则。对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

完整内容请查看敏捷软件开发 - 原则、模式与实践系列