OCP(开放封闭)原则

cundeng

在面向对象领域，有一个很著名的原则：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．只有在分类学角度上有意义时，才可以使用继承，不要从工具类继承。