OCP:开闭原则

开闭原则认为：设计良好的计算机软件应该易于扩展，同时抗拒修改。换句话说，一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩展。这就要处理好组件之间、类之间的依赖关系。

假设我们要设计一个Web页面上展示财务数据的系统，过了不久之后该系统的所有者又要求同样的数据需要形成一个报表能用打印机打印。显然我们需要增加一些代码来完成这个要求，但是这里更需要关注的是，满足新的需求需要更改多少旧代码。

一个号的软件架构设计师会努力将旧代码的修改需求量降至最小，甚至为0。如何实现呢？

• 将满足不同需求的代码分组（SRP）
• 调整依赖这些分组之间的依赖关系（DIP）

利用SRP，可以按下图展示的方式处理数据流。即先用一段分析程序处理原始的财务数据，以形成报表的数据结构，最后再用两个不同的报表生成器来产生报表。

image.png

接下来，需要调整源代码之间的依赖关系，创建抽象来隔离以后发生的同类变化。在具体实现上，我们会将整个程序进程划分成一系列的类，然后再将这些类分隔成不同的组件。下图中分成了Controller，Interactor，Database,Presenter和View。其中<DS>表示数据结构，<I>代表接口，开放箭头只带的是使用关系，闭合箭头指代的是实现与继承关系。类A指向类B的箭头意味着A的源代码中涉及了B，但是B的源代码中并不涉及A。图中FinancialDataMapper在实现接口时需要知道FinancialDataGateway的实现，而FinancialDataGateway则完全不必要知道FinancialDataMapper的存在。图中所有组件之间的关系都是单向依赖的，箭头都指向那些我们不经常更改的组件。

image.png

我们不想让Presenter上的修改影响到Controller，也不想让View上的修改影响到Presenter。最关键的是不想让任何修改影响到Interactor。整体来看Interactor是整个系统的核心组件，负责程序的核心逻辑，其他组件只是这个逻辑的辅助逻辑。局部来看，Controller是Presenter和View的核心组件。

如果现在需要再有某种形式的输出的话，只需要继承或者实现FinancialReportPresenter接口扩展就行了，不需要修改其他的位置。其中修改数据的存储的修改，其他的位置也不需要改变，只需要继承或者实现FinancialDataMapper就行了。

总结OCP是我们进行系统结构设计的主导原则，主要目标是让系统易于扩展，同时限制其每次被修改所影响的范围。实现方式是通过划分一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，似的高阶组件不会因低阶组件被修改而受到影响。无论组件多么封闭，都有一些无法封闭的变化，必须要预测那些可能变化的部分做抽象隔离来处理未来的变化。然而不成熟的抽象，会造成类的繁多。