OCP(开放封闭)原则
在面向对象领域，有一个很著名的原则：OCP（Open-Closed Principle） ， 它的核心含意是：一个好的设计应该能够容纳新的功能需求的增加，但是增加的 方式不是通过修改又有的模块（类） ，而是通过增加新的模块（类）来完成的， 也就是在设计的时候，所有软件组成实体包括接口，函数，函数等必须是可扩展 但不可修改的。 如果一个设计能够遵循 OCP， 那么就能够有效的避免上述的问题。
要是一个设计能够符合 OCP 原则， 就要求我们在进行设计时不能简单的以功 能为核心。要实现 OCP 的关键是抽象，抽象表征了一个固定的行为，但是对于这 个行为可以有很多个不同的具体实现方法。通过抽象，我们就可以用一个固定的 抽象的概念来代替哪些容易变化的数量众多的具体的概念， 并且使得原来依赖于 哪些容易变化的概念的模块，依赖于这个固定的抽象的概念，这样的结果就是： 系统新的需求的增加，仅仅会引起具体的概念的增加，而不会影响依赖于具体概 念的抽象体的其他模块。在实现的层面上，抽象体是通过抽象类来描述的，在 Java 中是接口（interface） 。
e 文原文：Software entities should be open for extension, but closed for modification.
原则内容：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．只有在分类学角度上有意义时，才可以使用继承，不要从工具类继承。
