程序设计的基本原则-开放封闭原则

开发过程中有什么痛点 ，因为变化、升级和维护等原因需要对原有逻辑进行修改时，很有可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有功能新测试。

 

怎么解决 —— 我们应该尽量通过扩展实体的行为来实现变化，而不是通过修改已有的代码来实现变化

 

具体一点呢 —— 类、模块和函数应该对扩展开放，对修改关闭。模块应该尽量在不修改原代码的情况下进行扩展。

 

核心 —— 用抽象构建框架，用实现扩展细节。

 

总结一下 —— 开发人员应该对程序中呈现的频繁变化的那些部分作出抽象，然后从抽象派生的实现类来进行扩展，当代码发生变化时，只需要根据需求重新开发一个实现类来就可以了。要求我们对需求的变更有一定的前瞻性和预见性，同时拒绝对于应用程序中的每个部分都刻意的进行抽象。

 

包含开闭原则在内，设计模式的六大原则，这里不详细介绍，简单列下：

 

单一原则 （SRP）: 实现类要职责单一,一个类只做一件事或者一类事，不要将功能无法划分为一类的揉到一起，答应我好吗

里氏替换原则（LSP）： 不要破坏继承体系，子类可以完全替换掉他们所继承的父类，可以理解为调用父类方法的地方换成子类也可以正常执行调用，爸爸打下的江山儿子继位得无压力好吗

依赖倒置原则（DIP）:我说下我的理解，如果某套功能或者业务逻辑可能之后会出现并行的另外一种模式或者较大的调整，那不如把这部分逻辑抽象出来，创建一个包含相关方法的抽象类，而实现类继承这个抽象类来重写抽象类中的方法，完成具体的实现，调用这些功能方法的类不需要关心自己调用的这些个方法的具体实现，只管调用这些抽象类中定义好的形式上的方法即可，不与实际实现这些方法的类发生直接依赖关系，方便之后的实现逻辑的替换更改；

接口隔离原则(ISP) : 在设计抽象类的时候要精简单一,白话说就是，A需要依赖B提供的一些方法，A我只用B的3个方法，B就尽量不要给A用不到的方法啦；

迪米特法则（LoD）降低耦合,尽量减少对象之间的直接的交互，如果其中一个类需要调用另一个类的某一个方法的话，可通过一个关系类发起这个调用，这样一个模块修改时，就可以最大程度的减少波及。

开放-封闭原则（OCP）告诉我们要对扩展开放，对修改关闭，你可以继承扩展我所有的能力，到你手里你想咋改咋改，但是，别 动我 本人 好吗？好的

23种设计模式基于以上6大基本原则结合具体开发实践总结出来的，万变不离其宗，有了这些基本的意识规范，你写出来的，搞不好就是某种设计模式٩(๑>◡<๑)۶