第4章 设计原则—开放-封闭原则

在软件设计模式中，这种不能修改，但可以扩展的思想也是一种设计原则，开放-封闭原则(The Open-Closed Principle，简称OCP)或叫开-闭原则。
概念：
开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

两个特征：一个是对于扩展是开放的（Open for extension），另一个是对于更改是封闭的（Closed for modification）。

我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推到重来。
怎样的设计才能面对需求的改变却可以保持相对的稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢，开放-封闭可以。
设计容易维护又不容易出问题的最好办法就是多扩展，少修改。(扩展可以添加新内容，当哪一天想使用之前的版本可以很容易通过替换类对象回退回来；如果是直接修改，要回退的话则需要把之前的代码重新开发一遍)。

设计人员需要清楚自己的目的是什么，什么地方可以扩展，什么地方不能修改。
开放-封闭原则的意思是说，在设计的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改了，如果新需求来了，我们增加一些类就完事了，原来的代码能不动则不动。

绝对的对修改关闭是不可能的。无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化(比如业务逻辑的实现有变化)。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化(实现扩展)。

我们是很难预先猜测程序可能变化的地方，但我们却可以在发生很小变化时，就及早去想办法应对更大变化的可能。也就是说，等到变化发生时立即采取行动。
在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化(可能发生的同类变化)。比如，最开始实现加法程序时，在client类中完成了，此时变化还没有发生。然后需要加一个减法功能，发现增加功能(减法)需要修改
原来的类(client类)，这就违背了‘开放-封闭原则’。这时该考虑重构程序，增加一个抽象的算法类，通过一些面向对象的手段，如继承，多态等来隔离具体加法、减法与client耦合(client不需要知道具体加法、减法类了，只需要知道有一个算法类即可)，需求依然可以满足，还能应对变化。
这时再增加其他如乘除等功能，就不需要去修改client以及已经存在的加减法类了，只需要增加乘除对应的算法子类即可。

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。（开放-封闭的精神所在）
并不是什么时候应对变化都是很容易的。我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。（如上边例子，加入加法、减法子类很多地方应用了，再考虑抽象、考虑分离就很困难，因为之前客户端很多用到加减法的地方可以不修改，这样达不到客户端与加减法解耦的效果，这时若要彻底解耦，则需要适应新的模式，在客户端用到加减法的地方进行修改，有工作量。所以当发生了变化时，要尽早处理重构）。

开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。

开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象。然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟
的抽象和抽象本身一样重要。