模式 开闭原则与哲学

“开闭原则”--对修改关闭，对扩展开放。在设计模式中的解释是这样的：“在软件设计开发中，不要对原有的代码进行修改，通过对原有代码进行扩展来实现相应功能。”

 

初学模式，这段话读着绝对拗口，甚至是矛盾重重。不修改，怎么去扩展呢？

 

 

其实，在尽量不修改代码的情况下进行扩展是可行的的，注意，这里是“尽量”。官方的解释中好像没发现有这个词的，因为如果较真的话，在不修改一点代码的情况下，根本无法实现扩展的。

 

下面，我们大家熟悉的“抽象”概念实现入手，看一下如何实现“开闭”。

 

在面向对象语言中，抽象类是一个比较常用的东西，那么，我们何时需要用到抽象类？用它来做什么？

 

从表象上来看，一般抽象类会有一些实现了的方法，还有一些没有实现的方法。只有继承了抽象类，并实现了抽象类没有实现的方法之后,才能使用。那么，这和开闭原则，又有啥关系呢。

 

抽象类中已经实现了的方法，理论上说不应该再被修改了，这就对应着开闭原则中的“对修改关闭”。

 

继承于某抽象类后，必须要实现抽象类没有实现的抽象方法，这可以理解为对抽象类进行了“扩展”。即：对与抽象类来说，我们一般不修改已经实现的方法，但需要对抽象方法进行实现（即扩展）。这就是开闭原则的一种体现。

 

 

         在设计开发中，为什么要实现开闭原则呢？

 

         我觉得开闭原则的好处主要在于下面两个方面：

 

         1 在设计初期，对需求进行好好地分析，考虑周全之后，设计出一个系统核心，这个核心，这个核心是整个系统最重要的部分，在未来应该是极难发生变化的（需要变化的东西我们将其做成抽象的，以便以后扩展和和替换）。这样增加系统的稳定性。

 

         2 在以后的开发或者维护中，如果当前的系统不能够满足需要，我们可以通过对可扩展部分的修改，赋予系统新的生命力，却不破坏整体结构。

        

         由上来看，要很好的满足开闭原则，主要在于前期的设计阶段。

        

         有人也许会问，我的前期设计可能就是没能够考虑的很周全，导致了错误的设计，或者客户对原有的需求提出了很大的改动，这时怎么办？

 

         这种情况有一定的发生可能，不管什么原因造成的，在一开始就错了，所以一步错、步步错。那么这种情况就真的一点都没法补救了吗？我认为不是，参考一下其他的模式，我们也许会想出一种比较周全的修改方式。

 

个人感觉开闭原则在整个设计模式中非常的重要，仿佛其他的设计模式都是应其而生、为其而活的。就算不懂得具体的设计模式方法，只要能够深刻的理解这个概念，那么对模式的理解已经比较深刻了，也许写不出很符合模式范例的模式代码，但相信会比死搬硬套好的多。这也许就像武侠中的无招胜有招吧。

 

PS:其实在生活中，开闭原则也存在于我们身边，比如在国家的改革改革过程中，如何进行破与立；在为人处事中，如何坚持自己的原则和适应社会等等，都是开闭原则的体现。有时候真感觉模式是一种哲学，值得大家深入研究探讨的。