本文参考《设计模式之禅》一书
开闭原则的定义：
Software entities like classes,modules and functions should be open for extension but closed formodifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。）
通俗讲：
其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
什么事软件实体？
软件实体包括以下几个部分：
● 项目或软件产品中按照一定的逻辑规则划分的模块。
● 抽象和类。
● 方法。
一个软件产品只要在生命期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。
开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
我们可以把变化归纳为以下三种类型：
● 逻辑变化
只变化一个逻辑，而不涉及其他模块，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
● 子模块变化
一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的，刚刚的书籍打折处理就是类似的处理模块，该部分的变化甚至会引起界面的变化。
● 可见视图变化
可见视图是提供给客户使用的界面，如JSP程序、Swing界面等，该部分的变化一般会引起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太大）。如果仅仅是界面上按钮、文字的重新排布倒是简单，最司空见惯的是业务耦合变化，什么意思呢？一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。
一般有变化时会涉及以下解决方法：
● 修改接口
接口应该是稳定且可靠的，不应该经常发生变化，否则接口作为契约的作用就失去了效能，牵一发而动全身（影响所有实现类），若有必要修改，说明设计本身存在问题。
● 修改实现类
相信大家在项目中经常使用的就是这样的办法，通过class文件替换的方式可以完成部分业务变化（或是缺陷修复）。但是可能影响与该类有依赖关系的其它类，所以该方案也不是一个最优的方案。
● 通过扩展实现变化
增加一个子类，高层次的模块通过父类类产生新的对象，完成业务变化对系统的最小化开发。好办法，修改也少，风险也小。
注意
开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。
如何使用开闭原则
1. 抽象约束
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。
因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：
第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；
第三，抽象层尽量保持稳定，一旦确定即不允许修改。
2. 元数据（metadata）控制模块行为
编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？
答案是尽量使用元数据来控制程序的行为，减少重复开发。
什么是元数据？
用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。
举个非常简单的例子，login方法中提供了这样的逻辑：先检查IP地址是否在允许访问的列表中，然后再决定是否
需要到数据库中验证密码（如果采用SSH架构，则可以通过Struts的拦截器来实现），该行为就是一个典型的元数据
控制模块行为的例子，其中达到极致的就是控制反转（Inversion of Control），使用最多的就是Spring容器。
3. 制定项目章程
在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，
约定优于配置。
4. 封装变化对变化的封装包含两层含义：
第一，将相同的变化封装到一个接口或抽象类中；
第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创
建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装，23个设计模
式都是从各个不同的角度对变化进行封装的。
最佳实践
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情
做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式
来“封装”未来的变化，我们在前5章中讲过如下设计原则。
● 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，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文件的替换方式修正了一个缺陷，
当然这种方式也可以应用到项目中，正在运行中的项目发现需要增加一个新功能，通过修改原有实现类的方式就可以
解决这个问题，前提条件是：类必须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。
● 项目规章非常重要
如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效的团队文化，章程是一个
团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优秀的章程能带给项目带来非常多的好处，如提高开
发效率、降低缺陷率、提高团队士气、提高技术成员水平，等等。
● 预知变化
在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生过，则需要考虑现有的架构
是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求，还要适应可能发生的变化，这才是一个
优良的架构。
开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向努力，可以非常显著地改
善一个系统的架构，真正做到“拥抱变化”。