解耦合手段之三：Open/Closed Principle

这又是一个面向对向的方法。Open/Closed Principle，可以译成“开/关原则”，“开-闭原则”或者“开放封闭原则”，是说“一个软件实体应当对扩展开放，对修改关闭( Software entities should be open for extension,but closed for modification.)。”这里所说的“实体”可以是函数、类、模块等等。

举个我所见过的比较差的例子吧。我们做的产品是由很多单板组成的分布式系统，为了适应不断提高的数据传输要求，其接口板经常要更新换代，不断升级。每次有新的接口板硬件以后，这块板上的几个程序模块都需要进行修改，甚至其它单板上的程序也要改动很多处。这种改动往往是在函数级别上的。系统的这种高耦合性给我们带来了很多麻烦，即费时又容易出问题。显然，我们的系统设计一定程度上违反了OCP，因为这个系统的模块都对修改开放，对扩展封闭。如果遵守了OCP，如果一段程序自身的功能没有BUG的话是不会被打开修改的，并且如果接口没有发生变化也不会对接口两端都进行改动的。

还是在Uncle Bob的著作《Agile Software Development Principles, Patterns, and Practice》（PPP）中有对于这个原则的详细描述。实现OCP原则，往往要用到继承和抽象接口。这篇文章 是和《PPP》中的内容一样的。

通常如果我们只是为了满足眼前的功能所写出的代码是不会自然而然的满足OCP和前面提到的SRP的，这就需要我们不断的对代码进行重构（Refactoring）。Martin Fowler在他的著作《重构-改善即有代码的设计》（Refactoring Improving the Design of Existing Code）一书中讲到了许多“Bad smells of code”——代码中的坏味道。如果你“闻”到你的代码中有他提到的“发散式变化(divergent change)”或者“散弹式修改（shotgun surgery）”那么你的代码可能违反了SRP或者OCP，需要重构。