设计模式设计模式的分类及六大原则

Posted 2020-11-22 wjqhuaxia

一、设计模式的分类

总体来说设计模式分为三大类：

　　创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

　　结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

　　行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

　　其实还有两类：并发型模式和线程池模式。

二、设计模式的六大原则

• 单一职责原则

• 里氏替换原则

• 依赖倒置原则

• 接口隔离原则

• 迪米特原则

• 开闭原则

单一职责

• 概念：对功能进行分类，代码进行解耦

• 栗子：一个网络请求框架大致分为：请求类，缓存类，配置类；不能把这三个功能混合在一起，必须分成三个类分别去实现不同的功能

里氏替换

• 概念：在继承类时，除了扩展一些新的功能之外，尽量不要删除或者修改对父类方法的引用，也尽量不要重载父类的方法

• 栗子：每个类都是Object的子类，Object类中有一个toString()的方法，假如子类重写该方法并且返回null，这个子类的下一级继承返回的都是null，那么在不同开发人员维护时可能考虑不到这个问题，并且很可能会导致程序崩溃

依赖倒置

• 概念：高层模块不依赖低层次模块的细节，高层次就是不依赖细节而是依赖抽象（不依赖具体的类，而是依赖于接口）

• 栗子：某个网络框架为了满足不同开发者的需求，即能使用高效的OkHttp框架，也可以使用原生的API。正所谓萝卜白菜各有所爱，那么是如何进行切换的呢，这个时候需要面向接口编程思想了，把一些网络请求的方法封装成一个接口，然后分别创建OkHttp和原生API的接口实现类，当然也方便后续其他开发人员进行扩展其他网络框架的应用

接口隔离

• 概念：在定义接口方法时应该合理化，尽量追求简单最小，避免接口臃肿

• 栗子：在实际开发中，往往为了节省时间，可能会将多个功能的方法抽成一个接口，其实这设计理念不正确的，这样会使接口处于臃肿的状态，这时就需要合理的拆分接口中的方法，另外抽取成一个独立的接口，避免原有的接口臃肿导致代码理解困难

迪米特 | 最少知道

• 概念：一个对象应该对其他对象有最少的了解；一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。只与直接的朋友通信。每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。

• 栗子：一般在使用框架的时候，框架的开发者会抽出一个类供外部调用，而这个主要的类像是一个中介一样去调用框架里面的其他类，恰恰框架里面其他类一般都是不可访问（调用）的，这个框架就遵守了迪米特原则，其他开发人员只关心调用的方法，并不需要关心功能具体如何实现

开闭

• 概念：类、模块和函数应该对扩展开放，对修改关闭

• 栗子：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试，整个流程对开发周期影响很大，这个时候就需要开闭原则来解决这种问题

总结

• 单一职责原则告诉我们实现类要职责单一

• 里氏替换原则告诉我们不要破坏继承体系

• 依赖倒置原则告诉我们要面向接口编程

• 接口隔离原则告诉我们在设计接口的时候要精简单一

• 迪米特原则告诉我们要降低耦合

• 开闭原则是总纲，告诉我们要对扩展开放，对修改关闭

作者：android轮子哥
链接：https://www.jianshu.com/p/068b2d0ce4e6