6大设计原则之6--开闭原则

开闭原则的定义

开闭原则是Java世界里最基础的设计 原则，它指导我们如何建立一个稳定的、灵活的系统，先来看开闭原则的定义： Software entities like classes,modules and functions should be open for extension but closed for modifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。）

开闭原则的定义已经非常明确地告诉我们：软件实体应该对扩展开放，对修改关闭，其 含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。 那什么又是软件实体呢？软件实体包括以下几个部分：

•  项目或软件产品中按照一定的逻辑规则划分的模块。

• 抽象和类。

• 方法。

我们可以把变化归纳为以下三种类型： 

• 逻辑变化 只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是a*b+c，现在需要修改为 a*b*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照 相同的逻辑处理。

• 子模块变化 一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层 模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的

• 可见视图变化 可见视图是提供给客户使用的界面，如JSP程序、Swing界面等，该部分的变化一般会引 起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太大）。如果仅仅是界 面上按钮、文字的重新排布倒是简单，最司空见惯的是业务耦合变化，什么意思呢？一个展 示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处 理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这 就要看我们原有的设计是否灵活。

为什么要采用开闭原则

每个事物的诞生都有它存在的必要性，存在即合理，那开闭原则的存在也是合理的，为 什么这么说呢？ 首先，开闭原则非常著名，只要是做面向对象编程的，甭管是什么语言，Java也 好，C++也好，或者是Smalltalk，在开发时都会提及开闭原则。 其次，开闭原则是最基础的一个原则，前五章节介绍的原则都是开闭原则的具体形态， 也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖。换一个角度 来理解，依照Java语言的称谓，开闭原则是抽象类，其他五大原则是具体的实现类，开闭原 则在面向对象设计领域中的地位就类似于牛顿第一定律在力学、勾股定律在几何学、质能方 程在狭义相对论中的地位，其地位无人能及。 最后，开闭原则是非常重要的，可通过以下几个方面来理解其重要性。

•  开闭原则对测试的影响：所有已经投产的代码都是有意义的，并且都受系统规则的约束，这样的代码都要经 过“千锤百炼”的测试过程，不仅保证逻辑是正确的，还要保证苛刻条件（高压力、异常、错 误）下不产生“有毒代码”（Poisonous Code），因此有变化提出时，我们就需要考虑一下， 原有的健壮代码是否可以不修改，仅仅通过扩展实现变化呢？否则，就需要把原有的测试过 程回笼一遍，需要进行单元测试、功能测试、集成测试甚至是验收测试，现在虽然在大力提 倡自动化测试工具，但是仍然代替不了人工的测试工作。

• 开闭原则可以提高复用性：在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立 实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。那为什 么要复用呢？减少代码量，避免相同的逻辑分散在多个角落，避免日后的维护人员为了修改 一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码，然后发出对开发人 员“极度失望”的感慨。那怎么才能提高复用率呢？缩小逻辑粒度，直到一个逻辑不可再拆分 为止。

• 开闭原则可以提高可维护性：一款软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能要对程序进行扩 展，维护人员最乐意做的事情就是扩展一个类，而不是修改一个类，甭管原有的代码写得多 么优秀还是多么糟糕，让维护人员读懂原有的代码，然后再修改，是一件很痛苦的事情，不 要让他在原有的代码海洋里游弋完毕后再修改，那是对维护人员的一种折磨和摧残。

• 面向对象开发的要求：万物皆对象，我们需要把所有的事物都抽象成对象，然后针对对象进行操作，但是万物 皆运动，有运动就有变化，有变化就要有策略去应对，怎么快速应对呢？这就需要在设计之 初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。                

如何使用开闭原则；

开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，但是开闭原则 并不局限于这么多，它“虚”得没有边界，就像“好好学习，天天向上”的口号一样，告诉我们 要好好学习，但是学什么，怎么学并没有告诉我们，需要去体会和掌握，开闭原则也是一个 口号，那我们怎么把这个口号应用到实际工作中呢？

• 抽象约束：抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性， 可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且 能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边 界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽 量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修 改。

• 元数据（metadata）控制模块行为：编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？答案是尽量使用元数据来控 制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是 配置参数，参数可以从文件中获得，也可以从数据库中获得。

• 制定项目章程：在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的 约定，对项目来说，约定优于配置。
  

• 封装变化：对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二， 将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或 抽象类中。封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳 定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到 或“第六感”发觉有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行 封装的。

最佳实践

软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。 我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我 们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化，6大设计原则如下： 

•  Single Responsibility Principle：单一职责原则

• Open Closed Principle：开闭原则

•  Liskov Substitution Principle：里氏替换原则

•  Law of Demeter：迪米特法则

•  Interface Segregation Principle：接口隔离原则

•  Dependence Inversion Principle：依赖倒置原则

把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起 来就是SOLID（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立 稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的 精神领袖。我们在使用开闭原则时要注意以下几个问题。

• 开闭原则也只是一个原则：开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但 是遵循这6大设计原则基本上可以应对大多数变化。因此，我们在项目中应尽量采用这6大原 则，适当时候可以进行扩充，例如通过类文件替换的方式完全可以解决系统中的一些缺陷。 大家在开发中比较常用的修复缺陷的方法就是类替换，比如一个软件产品已经在运行中，发 现了一个缺陷，需要修正怎么办？如果有自动更新功能，则可以下载一个.class文件直接覆 盖原有的class，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文 件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现 需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必 须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

• 项目规章非常重要：如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效 的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优 秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提 高技术成员水平，等等。

• 预知变化：在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生 过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合 现有的需求，还要适应可能发生的变化，这才是一个优良的架构。 开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向 努力，可以非常显著地改善一个系统的架构，真正做到“拥抱变化”。
  

转载于:https://my.oschina.net/u/134516/blog/596592