面向对象设计的SOLID原则

开放封闭原则(The Open Closed Principle)

** 一个软件实体如类、模块和函数应该对扩展开放,对修改代码关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展**

软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。如果不是调用实体的解耦,尽量不要去修改实体的内容,避免实体自己的逻辑调用出错

里氏替换原则(The Liskov Substitution Principle)

** 所有引用父类的地方必须能透明地使用其子类的对象**

简而言之,就是遵循父类的定义原则(参数及参数类型、返回值及其类型、 逻辑处理。。。)。当一个子类继承了父类,那么子类的一些表现最好和父类的一致,保证有引用父类的地方,引用该子类也不会报错。

依赖倒置原则(The Dependency Inversion Principle)

**高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
抽象不应该依赖于细节,细节应该依赖于抽象 **

这个和上面的开放封闭原则类似,高层模块模块不应该依赖底层模块,而是依赖于底层抽象出来的接口,剩下的有底层模块来完成,这个是需要底层模块开发出来时就考虑到的;而抽象出来的接口不要去关心具体实现的细节,但是细节应该依赖这个抽象的定义。比如,实现一个支付模块,对接支付的第三方有很多种,支付宝、微信、信用卡等。这时候如果开发了一个通用的支付对象,剩下的对接不同支付平台的工作交给高层模块来做。此时的高层模块不应该依赖底层的具体实现的细节,而是要实现底层抽象出来的接口;而抽象出来的接口不用关心具体是如何去对接不同的平台的,但是对应平台的细节应该要遵循接口的定义,如这里要你去对接支付平台,而你实现了去下载图片,这自然就是不行的

接口隔离原则(The Interface Segregation Principle)

使用多个专用的接口,而不是使用单一的总接口,即调用端不应该依赖那些它不需要的接口

当调用端去调用底层的模块,而底层的模块要求调用端必须实现它的所有抽象接口,但是,调用端去调用底层的模块不需要使用全部的抽象接口,这时候就会产生不必要的工作。接口隔离原则强调,调用端不应该依赖那些不需要的接口

单一职责原则(The Single Responsibility Principle)

不要存在多于一个导致类变更的原因。即一个类只负责一项职责

这个原则就是我们常说的解耦,将不同的功能让不同的模块来实现,当发生变动时只需要修改其中的某个模块即可

设计模式的分类

创建型模式:

工厂模式、抽象模式、创建者模式、原型模式、单例模式

结构型模式:

适配器模式、桥模式、组合模式、装饰模式、外观模式、享元模式、代理模式

行为型模式:

解释器模式、责任链模式、命令模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、访问者模式、模板方式模式

版权声明:本文为ivy-blogs原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/ivy-blogs/p/12697116.html