“开-闭”原则 （Open-Closed principle, OCP）
- 一个软件实体应当对扩展开放，对修改关闭。
Software entities should be open for extension, but closed for modification.
在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
- “可变性的封装原则”从工程的角度讲解了如何实现“开-闭”原则。
“可变性的封装原则”意味着两点：
* 一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。继承应当被看做是封装变化的方法，而不应当被认为是从一般的对象生成特殊的对象方法。
* 一种可变性不应当与另一种可变性混合在一起。所有的类图的继承结构一般不会超过两层，不然就意味着将两种不同的可变性混合在一起。
“开-闭”原则与其他原则的关系：
- 里氏代换原则是，任何基类可以出现的地方，子类一定可以出现。
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体体现，所以里氏代换原则是对实现抽象化的具体步骤的规范。违反里氏代换原则的，也违背“开-闭”原则，反之不一定成立。
- 依赖倒转原则是，要依赖于抽象，不要依赖于实现。
“开-闭”原则是目标，依赖倒转原则是手段。
- 合成/聚合复用原则是，要尽量使用合成/聚合，而不是继承关系达到复用的目的。
合成/聚合复用原则与里氏代换原则相辅相成，两者都是实现“开-闭”原则的具体步骤的规范。
- 迪米特法则是，一个软件实体应当与尽可能少的其他实体发生相互作用。
一个遵守迪米特原则设计出来的系统在功能需要扩展时，会相对更容易地做到对修改的关闭。
- 接口隔离原则是，应当为客户端提供尽可能小的单独的接口，而不是提供大的总接口。
接口隔离原则与广义的迪米特法则都是对一个软件实体与其他的软件实体的通信的限制。遵循接口隔离原则，会使一个软件系统在功能扩展的过程当中，不会将修改的压力传递到其他的对象。
一个重构方法的讨论
“将条件转移语句改写成为多态性”是一条广为流传的代码重构做法。
这一做法本身并不能保证“开-闭”原则，应当以“开-闭”原则判断是否需要改写成多态。条件转移并不是错误，如果需要，完全可以选择使用条件转移。
如果一个条件转移语句确实封装了某种商务逻辑的可变性，那么将此种可变性封装起来就符合“开-闭”原则设计思想了。如果一个条件转移语句没有涉及重要的商务逻辑，或者不会随着时间的变化而变化，也不意味着任何的可扩展性，那么它就没有涉及任何有意义的可变性。这时候将这个条件转移语句改写成多态性就是一种没有意义的浪费。
- 抽象类应当拥有尽可能多的共同代码
在一个继承的等级结构中，共同的代码应当尽量向等级结构的上方移动。把重复的代码从子类里面移动到超类里面，可以提高代码的复用率。在代码发生改变时，设计师只需要修改一个地方。
- 抽象类应当拥有尽可能少的数据
与代码的移动方向相反，数据的移动方向是从抽象类到具体类，向等级结构的下方移动。一个对象的数据不论是否使用都会占用资源，所以应当放到等级结构的低端。
- 什么时候才应当使用继承复用
1．子类是超类的一个特殊种类，而不是超类的一个角色，Is-A才符合继承关系。
2．永远不会出现需要将子类换成另一个类的子类的情况。
3．子类具有扩展超类的责任，而不是具有置换掉（Override）和注销掉（Nullify）超类的责任。
4．只有在分类学角度上有意义时，才可以使用继承，不要从工具类继承。
里氏代换原则 （Liskov Substitution Principle, LSP）
- 定义严格表达：
如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。
简单说，任何基类可以出现的地方，子类一定可以出现。
- 从代码重构的角度理解：
西方著名的思辨，正方形是否是长方形的子类的问题。
这个例子意味着里氏代换与通常的数学法则和生活常识有不可混淆的区别。应当尽量从抽象类继承，而不从具体类继承。
网友评论