设计原则之开闭原则–对扩展开发对修改关闭
开闭原则(Open Closed Principle) OCP，这个原则是说对扩展可以开放，但是对修改要关闭。
这个原则的英文描述是software entities(modules,classes,functions,etc.) should be open for extension, but closed for modification.。
为什么要使用开闭原则
引用大话设计模式书中的故事。在香港澳门回归的时候，我国使用了一国两制的方针。**这其实就是没有修改任何地方，但却扩展了我国的领土。**这也就是对修改关闭，对扩展开放。
开放封闭原则，是说软件实体应该可以扩展，但是不可修改。
在现在的开发中，改需求是一个很常见的事情，我们经常需要**这个需求要改成这样，明天上线！！**这种事情。这时候我们加班加点改完一个类实现了新需求。这个时候发现由于这个类的依赖太多，我们的修改引起了其他地方的bug，那我们需要整体测试，然后各种修改，还可能引起更多的bug，如此耗时耗力。
在思考另外一个场景，同样我们实现了需求，这个时候没出其他问题，但是！！！这个需求要改回去，你把之前的代码拿出来吧。我相信你一定很不爽的，如果我们可以通过git来回滚到之前的代码还好，如果我们之前的代码在本地没有提交这个时候我们又修改完了，那，呵呵，再改回去吧，鬼知道之前代码啥样。
如果我们遵循开闭原则，不是通过修改类来完成，而是通过扩展类的方式来完成这个新需求，那么我们就避免了这些问题，扩展不会引起其他的未知bug。不会影响到其他的类。如果要改回去我们原来的代码也还在。这就是开闭原则的好处了。
如何使用开闭原则
无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化封闭做出选择。它必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离哪些变化。
我们开发中，最开始的时候，很难预测接下来的变化。但是，一旦发生变化我们可以根据变化来采取行动，进行抽象重构。使得接下来通过扩展和少量的必要修改来应对需求的变化。
开闭原则是面向对象设计的核心所在。**遵循这个原则可以带来面向对象技术所生成的巨大好处，也就是可维护，可扩展，可复用，灵活性好。**我们应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于程序中的每个部分都刻意的进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
我们可以在开发的开始阶段对接下来能预测到的变化留出扩展空间，然后再不断的持续重构开发代码中一直遵循开闭原则。
很多设计模式都是以提高扩展性为目的。最常用的方法有：多态，依赖注入，基于接口编程等。
参考资料：
- 大话设计模式
- 极客时间设计模式之美
