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

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

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

---

开闭原则（Open Closed Principle，OCP）

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

---

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

---

开闭原则的含义

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

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

---

开闭原则的作用

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

---

壹 玉帝招安美猴王

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

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

贰 弹性工作制

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

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

叁 《太玄》论 “固革”

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

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

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

---

开闭原则的实现方法

“抽象约束，封装变化”

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

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