开放封闭原则

开放封闭原则（Open Closed Principle）描述

符合开放封闭原则的模块都有两个主要特性：

1. 它们 “面向扩展开放（Open For Extension）”。
   也就是说模块的行为是能够被扩展的。当应用程序的需求变化时，我们可以使模块表现出全新的或与以往不同的行为，以满足新的需求。
2. 它们 “面向修改封闭（Closed For Modification）”。
   模块的源代码是不能被侵犯的，任何人都不允许修改已有源代码。

“对扩展开放”的关键是”抽象”
       在使用面向对象设计技术时，可以创建固定的抽象和一组无限界的可能行为来表述。这里的抽象指的是抽象基类，而无限界的可能行为则由诸多可能衍生出的子类来表示。为了一个模块而篡改一个抽象类是有可能的，而这样的模块则可以对修改封闭，因为它依赖于一个固定的抽象。然后这个模块的行为可以通过创建抽象的衍生类来扩展。

开放封闭原则的例子

1.扩展实现（书店售书的经典例子，下为其类图）：
这里写图片描述

源代码如下：
书籍接口以及书籍类别：

书店实现：

运行结果：

现在改变需求:书店决定，40元以上打8折，40元以下打9 折。如何解决这个问题呢？
第一个办法：
       修改接口。在IBook上新增加一个方法getOffPrice()，专门进行打折，所有实现类实现这个方法。
但是这样修改的后果就是实现类NovelBook要修改,BookStore中的main方法也修改，同时Ibook作为接口应该是稳定且可靠的，不应该经常发生变化，否则接口做为契约的作用就失去了效能，其他不想打折的书籍也会因为实现了书籍的接口必须打折，因此该方案被否定。

第二个办法：
       修改实现类。修改NovelBook 类中的方法，直接在getPrice()中实现打折处理，这个应该是大家在项目中经常使用的就是这样办法，通过class文件替换的方式可以完成部分业务（或是缺陷修复）变化，该方法在项目有明确的章程（团队内约束）或优良的架构设计时，是一个非常优秀的方法。
但是该方法还是有缺陷的，例如采购书籍人员也是要看价格的，由于该方法已经实现了打折处理价格，因此采购人员看到的也是打折后的价格，这就产生了信息的蒙蔽效果，导致信息不对称而出现决策失误的情况。该方案也不是一个最优的方案。

第三个办法：最优方案
        通过扩展实现变化。增加一个子类 OffNovelBook，覆写getPrice方法，高层次的模块（也就是static静态模块区）通过OffNovelBook类产生新的对象，完成对业务变化开发任务。好办法，风险也小，我们来看类图：

源代码如下：
书籍接口以及书籍类别：

书店实现：

运行结果：

2.扩展接口再扩展实现：
上例中，书店又增加了计算机类书籍，该类书还有一个独特特性：面向的是什么领域，修改后的类图如下：

**计算机书籍接口以及计算机书籍类： **

书店实现：实现IcomputerBook就可以，而BookStore类没有做任何的修改，只是在static静态模块中增加一条数据，代码如下：

运行结果

转载博客：https://blog.csdn.net/yabay2208/article/details/73927991