开闭原则OCP（Open-Close Principle）被称作是OOD的基石，是OOD最重要的原则之一。 这个原则由大师Bertrand Meyer在1988年提出（汗，那个时候恐怕国内还很少人知道OO，甚至计算机为何物）：Software entities should be open for extension,but closed for modification。多简单啊？！这个原则的意思大概是说：软件对扩展应该是开发的，对修改应该是关闭的。说的更通俗点儿，就是说我们开发了一个软件，应该可以对它进行功能扩展（开放），而在进行这些扩展的时候，不需要对原来的程序进行修改（关闭）！ 为什么会有这样的要求呢？如果一个软件是符合OCP原则的，那么至少，我们有两个极大的好处： 1.在软件可用性上，非常灵活。你可以在软件完成对软件进行扩展，加入新的功能。这样，这个软件就可以通过不断的增加新模块满足不断变化的新需求！ 2.由于对软件原来的模块不能修改，因此不用担心软件的稳定性。 目前，对OCP的实现，主要的一条就是抽象，就是我们常常挂在嘴边的要面向抽象（接口）。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体类必须提供的方法的特征作为系统设计的抽象层，这个抽象层要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象层不需修改；同时由于可以从抽象层导出一个或多个新的具体类可改变系统的行为，因此对于可变的部分，系统设计对扩展是开放的。 关于系统可变的部分，还有一个更具体的对可变性封装原则（Principle of Encapsulation of Variation,EVP），从工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能（或允许）发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。 我们很容易就可以想到，在设计的开始就罗列系统所有可能的行为加入到抽象底层是不可能的（实际上也是不合算的），对所有的可变因素进行预计和封装也不太现实，因此，开闭原则很难被完全实现，只能在某些模块、某种程度上、某个限度内符合OCP的要求。所以可以说，OCP具有理想主义的色彩，是OOD的终极目标。因此，针对OCP的实现方法，许多OOD的大师都费尽心机，研究OCP的实现方式。后面要提到的里氏代换原则、合成复用原则，依赖倒转原则，接口隔离原则，抽象类，迪米特法则等，都可以看作是OCP的实现方法。版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
