设计原则之壹——开闭原则

以下七种设计原则是软件设计模式尽量遵循的原则，各种原则要求的侧重点不同。

开闭原则 是总纲，它告诉我们要对扩展开放，对修改关闭；
里氏替换原则 告诉我们不要破坏继承体系；
依赖倒置原则 告诉我们要面向接口编程；
单一职责原则 告诉我们实现类要职责单一；
接口隔离原则 告诉我们在设计接口的时候要精简单一；
迪米特法则 告诉我们要降低耦合度；
合成复用原则 告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

开闭原则（Open Closed Principle，OCP）

软件实体应当对扩展开放，对修改关闭。
Softwar entities should be open for extension, but closed for modification.

经典力学的基石是牛顿三大定律。面向对象的可复用设计的第一块基石，便是开闭原则。

开闭原则的含义

这里的“软件实体”从不同层面来看，可以包括系统模块、类与接口、方法。
当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

所有的软件系统，它们的需求都会随时间发生改变，开闭原则要求当系统面临新的需求时，系统的设计必须是稳定的，即：
① 通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。
② 已有的软件模块的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。

开闭原则的作用

① 对软件测试的影响：
软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的代码仍然能够正常运行。
② 可以提高代码的可复用性：
粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
③ 可以提高软件的可维护性
遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

壹玉帝招安美猴王

大闹天宫时的美猴王是玉帝的新挑战。
美猴王说：“皇帝轮流做，明年到我家。只教他搬出去，将天宫让与我！”
对于这项挑战，太白金星给玉皇大帝提出了建议：
“降一道招安圣旨，把他宣来上界……与他籍名在箓……一则不用动众劳师，二则收仙有道。”

“劳师动众，更改既有天规秩序”，便是“闭”的对象，不可为之；
而“收仙之道”便是“开”的方式，是应对这个新挑战的方法。
通过给美猴王一个“弼马温”的官职，便可使现有系统在不改变既有规则秩序的前提下，将妖猴纳入现有体系中，为其指定一个职位，从而扩展来这一秩序，满足了新的变化的需求。
用面向对象的语言来讲，不允许改变的是系统的抽象层，而允许扩展的是系统的实现层。

贰弹性工作制

公司老板规定，早上九点上班，不许迟到。有几个公司骨干，总是迟到。怎么办？
如果严格执行考勤制度，迟到扣钱的话，有些不近人情。
因为有的员工家离公司太远；有的要送孩子上学可能会堵车；还有的前一天加班比较累。
如果让他们因为特殊原因打报告，一来会很繁琐让人生厌，二来其他的同事也会不满意，一个规则不一视同仁，便显得不公正。
那怎么解决？
一种思路是，保证8小时的工作量是关键，所以可以考虑弹性上班9：00~10：00上班，早到可以早走，晚到要晚走，每天8小时工作时间即可。这其实是对工作时间的修改关闭，必须保证8小时每天；但是对时间制度的扩展进行了开放，可以自由控制上班和小班时间。
另外一种思路是，9点上班的规则不需要修改（关闭），但是可以通过调休1小时来对迟到进行处理，即对迟到状态的改变开放，将迟到变为调休。

对规则的核心不能修改，这是“闭”；弹性工作/ 调休替换迟到则是“开”。

叁《太玄》论 “固革”

西汉杨雄的《太玄》一书说：“知固而不知革，物失其则；知革而不知固，物失其均。”

这句话的意思是说，知其序法，固守不变者无所存，知变通而不遵其法者变则死。
唯变而有序者生，人事家国皆循此道。

翻译过来就是：你接手了个老系统，需求来了，你不敢改，就失业；你改，但不管不顾已有的系统架构，就会面临屎山崩塌。
（我想起了一张动图）

开闭原则的实现方法

“抽象约束，封装变化”

即通过接口或者抽象类作为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

实际中，
无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。
既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出左右可能发生的变化种类，然后构造抽象来隔离那些变化。
开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象
对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。
拒绝不成熟的抽象和抽象本身一样重要。