原则内容：OCP原则就是"开-闭原则"，一个软件应该对扩展开放，对修改关闭。
解释 ：在设计一个模块的时候，应当使得这个模块可以在不被修改的前提下面被扩展。换言之，应该可以在不必修改源代码的情况下改变这个
模块的行为。这个原则有2点要求：
×：扩展开放
×：关闭修改
满足OCP原则系统的优点：
×：通过扩展已有的软件系统，提供新的行为，可以使得软件系统满足新需求
×：已有的软件模块，特别是重要的抽象层模块不能做变更，这使得变化中的软件系统有一定的稳定性和延续性。
如何实现OCP原则：
1、抽象是关键。
   对需要设计的系统进行抽象，在此前提下面，让抽象的实现机制千变万化。这个抽象层必须预见到所有的可能的扩展，任何实现的改变都不会改变该抽象结构。这样使得系统的抽象层无需修改，从而满足OCP原则的第二条－关闭修改。
2、对可变性的封装原则
   OCP从另一个角度来说，就是EVP(principle of Encapsulation Variation)原则。即找到系统的可变因素，将之封装起来。这个原则意味着2点：
×：一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。继承应当被看    做是封装变化的方法，而不应当被认为是从一般的对象生成特殊的对象方法。
×：一种可变性不应当与另一种可变性混合在一起。所有的类图的继承结构一般不会超过两层，不然就意味着将两种不同的可变性混合在一起。
与其他设计原则的关系
LSP原则：这个原则是说任何基类出现的地方，子类一定可以出现。
这个原则是对OCP原则的补充，基类和子类的关系就是抽象化的具体体现，所以LSP原则是对实现抽象化的具体步骤的规范。一般来说，违背了LSP原则，一定违反了OCP原则，反之不一定成立。
CARP原则：这个原则讲的是要尽可能的多用合成/聚合，而不是继承关系达到复用的目的。
CARP原则和LSP原则相辅相成。二者都是对实现OCP原则的具体步骤的规范。前者要求设计师首先考虑合成/聚合关系；后者要求在使用继承关系的时候， 必须确定这个关系是符合一定条件的。CARP原则是OCP原则的必要条件，违反了这个原则，就无法使系统实现OCP原则这个目标。
DIP原则：这个原则是说要依赖于抽象，不要依赖于实现。
DIP原则和OCP原则是目标和手段的关系。OCP是目标，DIP是手段。要想实现OCP原则，必须坚持DIP原则。违反了DIP原则，则不可能达到OCP原则要求。

LoD原则：这个原则讲的是一个软件实体应该尽可能少的和其他实体发生作用。
当一个system面临功能扩展的时候，其中会有一些模块，他们需要修改的压力比其他的模块要大一些，如果这些模块是相对孤立的，那么他们就不会将修改的 压力传递给其他模块。根据LoD原则设计的系统，在功能需要扩展的时候，会相对容易的做到对修改的关闭。LoD原则是一条通向OCP原则的道路。
ISP原则：这个原则是说，应当为客户端提供尽可能小的单独接口，而不要提供大的总接口。ISP原则和LoD原则讲的都是一个软件实体与另一个软件实体的通讯限制。广义的LoD原则要求尽可能限制通讯的宽度和深度，ISP原则所限制的是通信宽度。
一个重构方法的讨论
“将条件转移语句改写成为多态性”是一条广为流传的代码重构做法。

这一做法本身并不能保证“开-闭”原则，应当以“开-闭”原则判断是否需要改写成多态。条件转移并不是错误，如果需要，完全可以选择使用条件转移。

如果一个条件转移语句确实封装了某种商务逻辑的可变性，那么将此种可变性封装起来就符合“开-闭”原则设计思想了。如果一个条件转移语句没有涉及重 要的商务逻辑，或者不会随着时间的变化而变化，也不意味着任何的可扩展性，那么它就没有涉及任何有意义的可变性。这时候将这个条件转移语句改写成多态性就 是一种没有意义的浪费。
抽象类应当拥有尽可能多的共同代码

 在一个继承的等级结构中，共同的代码应当尽量向等级结构的上方移动。把重复的代码从子类里面移动到超类里面，可以提高代码的复用率。在代码发生改变时，设计师之需要修改一个地方。

抽象类应当拥有尽可能少的数据

与代码的移动方向相反，数据的移动方向是从抽象类到具体类，向等级结构的下方移动。一个对象的数据不论是否使用都会占用资源，所以应当放到等级结构的低端。

 

什么时候才应当使用继承复用

1．子类是超类的一个特殊种类，而不是超类的一个角色，Is-A才符合继承关系。

2．永远不会出现需要将子类换成另一个类的子类的情况。

3．子类具有扩展超类的责任，而不是具有置换掉（Override）和注销掉（Nullify）超类的责任。

4．只有在分类学角度上有意义时，才可以使用继承，不要从工具类继承。