概述
开闭原则是java 6大基本原则之一，而6大原则在软件开发中属于内功心法的存在，需要长期进行修炼，才能有所成就。今天就单独谈谈“开闭原则”，它的定义是：对扩展开放、对修改关闭。简单、直白的定义，确很难理解它到底想表达什么？
目的
想想如果软件只允许扩展，但是不允许修改会发生什么呢？旧的被测试过的代码，永远不会再次被改变，不改变意味着不会引入新的bug，不会产生影响，那系统将会一直保持稳定，只要测试保证新扩展的能力是稳定的。所以初步可以得出结论，开闭为了稳定。
如果系统只支持扩展，那么前期就只能尽可能的设计出高扩展性的代码，否则后期代码将无法进行升级，如果开闭这么影响我们的设计，那么，开闭是为了扩展
如果系统设计成高度的可扩展性，就需要将功能分解的足够小，而代码的颗粒度越小，代码的复用性就越高，这样想，开闭，似乎是为了复用
- 稳定性
- 扩展性
- 复用性
影响
如果追求极致的开闭会怎么样？那么我们需要在所有的地方预留扩展的可能，我们会设计出大量的接口，会对每一行代码进行抽象，会将每一个方法设计成一个类，每个类设计成一个组件，这样的代码符合 “稳定性”、“高扩展性”、“高复用性”；但是它牺牲了，可读性，可维护性，并且导致了代码的膨胀，性能的下降。
- 降低可读性
- 降低可维护性
- 增加代码量
- 性能下降
总结
基于以上，我们需要思考在什么情况下追求开闭，一般情况下，我们会针对易变部分代码的设计会追求开闭原则。基于一些符合开闭设计模式来优化它，比如：工厂模式、策略模式、状态模式等等。
例子
下面，我来写一个例子来追求开闭，并且一步步完善成 完全不用修改 的极致情况。我们来想一个故事，很久很久以前：
我们有一个宝宝，刚开始只能吃奶粉、后来长大了一点，一岁可以开始吃米糊了，等到两岁的时候可以开始吃水果了，三岁以后可以吃米饭和肉了。下面是我们的宝宝：
一年后：
n年后：
我们发现，宝宝的做饭方法一直在变，我们可以理解宝宝不符合开闭。我们观察发现，宝宝除了做饭方法，其他都没有变。那么只要把做饭方法抽离出来了，那么宝宝就符合开闭了。那我们让妈妈做饭把。
好样的，宝妈变得善变了，至少让一部分代码稳定下来了。一般情况下，我们都只能追求尽量的开闭，让修改的代码变得足够少。对于之前的宝宝而言，虽然改变的也只是做饭代码，但是没法发防护，做饭不会对宝宝产生影响，毕竟是宝宝的一部分。
我们接下来，继续降低代码的变更量：
好吧，这次用到了抽象，当宝妈已经没办法满足需求的时候，之前换成另外一个会做饭的宝爸来，宝爸不行了，就让奶奶来。我们只需要替换宝宝中的一行创建代码。（事实上宝宝里面修改了代码，都是有可能影响到宝宝的，一般情况下我们可以创建一个工厂类，这部分变化的颗粒分出去）
但是到目前为止，我们仍然需要修改一行代码，有没有办法我们不修改一行代码呢？我们可以利用编译时注解，来自动生成这一行代码，可以类似下面这种当时定义新的做饭类：
通过打上注解，在编译时可以自动生成做饭类，我们叫他机器人把。
注解自动生成代码的方法，大家可以百度自己搜索把，这部分代码太麻烦了，我也懒得写了