版权声明：本文为Jaiky_杰哥原创，转载请注明出处。This blog is written by Jaiky, reproduced please indicate. https://blog.csdn.net/jaikydota163/article/details/52761891
总结经验
近期自学Unity引擎，学到了关于设计模式这一块，以前学习Java多次接触设计模式，也在应用的开发过程中频繁使用。虽然开发过程中没有特意去强调使用设计模式，但设计模式的使用总是潜移默化的，现在回头再复习下设计模式具体实现，才发现自己在开发过程中自然而然的就运用到了。总之做任何事都是靠经验积累的，设计模式的出现也是靠实践总结出来的，虽然是做游戏开发，但逻辑依旧是相同的，看了几篇Blog觉得受益匪浅，在这里总结下再次学习的感悟。
开闭原则总结：
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，
可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
因此，当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了，
它只告诉我们对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的告诉我们。
以前，如果有人告诉我“你进行设计的时候一定要遵守开闭原则”，我会觉的他什么都没说，但貌似又什么都说了。因为开闭原则真的太虚了。
在仔细思考以及仔细阅读很多设计模式的文章后，终于对开闭原则有了一点认识。
其实，我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。
也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，
前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；
如果前面5项原则遵守的不好，则说明开闭原则遵守的不好。
其实，开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。
当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，
可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
因此，当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了，
它只告诉我们对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的告诉我们。
以前，如果有人告诉我“你进行设计的时候一定要遵守开闭原则”，我会觉的他什么都没说，但貌似又什么都说了。因为开闭原则真的太虚了。
在仔细思考以及仔细阅读很多设计模式的文章后，终于对开闭原则有了一点认识。
其实，我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。
也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，
前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；
如果前面5项原则遵守的不好，则说明开闭原则遵守的不好。
其实，开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。
当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。
