开放－封闭法则之我见

下面第一部分的资料都是关于开放－封闭法则的，我以蓝字标出，在这之后的第二部分是我对该法则的一些理解和引申。如果你以前并不知道该法则，请先阅读下面的第一部分。如果你想对该法则有进一步的了解甚至想应用到自己的项目中，那么第二部分的内容也许会对你有些帮助。

 

第一部分：

软件组成实体应该是可扩展的，但是不可修改的。

[ Software Entities Should Be Open For Extension, Yet Closed For Modification ]

开放－封闭法则

n         开放-封闭法则认为我们应该试图去设计出永远也不需要改变的模块。

n         我们可以添加新代码来扩展系统的行为。我们不能对已有的代码进行修改。

n         符合OCP的模块需满足两个标准：

F        可扩展，即“对扩展是开放的”（Open For Extension）－模块的行为可以被扩展，以需要满足新的需求。

F        不可更改，即“对更改是封闭的”（Closed for Modification）－模块的源代码是不允许进行改动的。

n         我们能如何去做呢？

F        抽象（Abstraction）

F        多态（Polymorphism）

F        继承（Inheritance）

F        接口（Interface）

 

n         一个软件系统的所有模块不可能都满足OCP，但是我们应该努力最小化这些不满足OCP的模块数量。

n         开放－封闭法则是OO设计的真正核心。

n         符合该法则便意味着最高等级的复用性（reusability）和可维护性（maintainability）。

OCP示例

n         考虑下面某类的方法：

n         以上函数的工作是在制订的部件数组中计算各个部件价格的总和。

n         若Part是一个基类或接口且使用了多态，则该类可很容易地来适应新类型的部件，而不必对其进行修改。

n         其将符合OCP

n         但是在计算总价格时，若财务部颁布主板和内存应使用额外费用，则将如何去做。

n         下列的代码是如何来做的呢？

n         这符合OCP吗？

n         当每次财务部提出新的计价策略，我们都不得不要修改totalPrice()方法！这并非“对更改是封闭的”。显然，策略的变更便意味着我们不得不要在一些地方修改代码的，因此我们该如何去做呢？

n         为了使用我们第一个版本的totalPrice()，我们可以将计价策略合并到Part的getPrice()方法中。

n         这里是Part和ConcretePart类的示例：

n         但是现在每当计价策略发生改变，我们就必须修改Part的每个子类！

n         一个更好的思路是采用一个PricePolicy类，通过对其进行继承以提供不同的计价策略：

 

 

n         看起来我们所做的就是将问题推迟到另一个类中。但是使用该解决方案，我们可通过改变Part对象，在运行期间动态地来设定计价的策略。

n         另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格。

单选法则

单选法则（the Single Choice Principle）是OCP的一个推论。

单选法则：

无论在什么时候，一个软件系统必须支持一组备选项，理想情况下，在系统中只能有一个类能够知道整个的备选项集合。

 

第二部分：

如果你已经理解了上面的开放－封闭法则，并且已经熟悉了上面的那个代码例子，那么你是否能够理解下面的内容：

一个软件系统可以通过扩展来应对已知类型的变化（需求），但是从没有任何软件系统可以在不更改代码的情况下应对未知类型的变化（需求）。

还拿上面的例子来作说明。如果所有part的计价方法都一样，则在class Part里只是简单返回该part的price即可，但正是由于出现了一个新的需求：某些part的计价方法和其它part是不一样的，则迫使class Part做出改变需要来灵活应对这种情况，在上面例子中灵活的做法就是增加一个class PricePolicy来应对这种情况。

请注意，在这个新的需求第一次出现时，对当前的软件系统来说，它是一个新的未知类型的变化（需求），因此需要通过修改代码来应对这种改变（新增interface PricePolicy）。当软件系统再次碰到这种类型的变化时，它已是一个已知类型的变化（需求），因此只需要扩展就可以应对（添加新的基于PricePolicy的实现类）。

因此，评判一个应对新变化的代码修改的标准自然也就出来了：代码改变后，如果再次有同类型的变化，系统只需扩展就可应对，那么这种修改是灵活的，是符合OCP法则的；如果需要改动原有的代码才能应对变化，那是一种非常糟糕的代码修改方法，是明显违背OCP法则的。正如下面的代码修改所示：

如果再出现一种需要特别计算的Part，恐怕又要再加一行else if语句了。

 

结论：

l         不要期望你的软件系统通过扩展应对未知类型的需求，应该调整软件架构来适应未知类型的变化

l         好的架构应该在项目初期就尽可能考虑到今后可能遇到的需求变动，并为此留下余地，也就意味着尽量减少未知变化的类型出现的几率，这会让你的架构保持稳定

l         OCP法则可以做为衡量代码修改的标准，请在修改代码的同时，牢牢记住OCP法则