** 一个软件实体如类、模块和函数应该对扩展开放，对修改代码关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展**
[========]
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。如果不是调用实体的解耦，尽量不要去修改实体的内容，避免实体自己的逻辑调用出错
** 所有引用父类的地方必须能透明地使用其子类的对象**
[========]
简而言之，就是遵循父类的定义原则（参数及参数类型、返回值及其类型、 逻辑处理。。。）。当一个子类继承了父类，那么子类的一些表现最好和父类的一致，保证有引用父类的地方，引用该子类也不会报错。
**高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象 **
[========]
这个和上面的开放封闭原则类似，高层模块模块不应该依赖底层模块，而是依赖于底层抽象出来的接口，剩下的有底层模块来完成，这个是需要底层模块开发出来时就考虑到的；而抽象出来的接口不要去关心具体实现的细节，但是细节应该依赖这个抽象的定义。比如，实现一个支付模块，对接支付的第三方有很多种，支付宝、微信、信用卡等。这时候如果开发了一个通用的支付对象，剩下的对接不同支付平台的工作交给高层模块来做。此时的高层模块不应该依赖底层的具体实现的细节，而是要实现底层抽象出来的接口；而抽象出来的接口不用关心具体是如何去对接不同的平台的，但是对应平台的细节应该要遵循接口的定义，如这里要你去对接支付平台，而你实现了去下载图片，这自然就是不行的
使用多个专用的接口，而不是使用单一的总接口，即调用端不应该依赖那些它不需要的接口
[========]
当调用端去调用底层的模块，而底层的模块要求调用端必须实现它的所有抽象接口，但是，调用端去调用底层的模块不需要使用全部的抽象接口，这时候就会产生不必要的工作。接口隔离原则强调，调用端不应该依赖那些不需要的接口
不要存在多于一个导致类变更的原因。即一个类只负责一项职责
这个原则就是我们常说的解耦，将不同的功能让不同的模块来实现，当发生变动时只需要修改其中的某个模块即可
工厂模式、抽象模式、创建者模式、原型模式、单例模式
适配器模式、桥模式、组合模式、装饰模式、外观模式、享元模式、代理模式
解释器模式、责任链模式、命令模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、访问者模式、模板方式模式
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论