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

Posted wjqhuaxia

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了设计模式设计模式的分类及六大原则相关的知识,希望对你有一定的参考价值。

一、设计模式的分类

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

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

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

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

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

二、设计模式的六大原则

  • 单一职责原则

  • 里氏替换原则

  • 依赖倒置原则

  • 接口隔离原则

  • 迪米特原则

  • 开闭原则

单一职责

  • 概念:对功能进行分类,代码进行解耦

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

里氏替换

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

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

依赖倒置

  • 概念:高层模块不依赖低层次模块的细节,高层次就是不依赖细节而是依赖抽象(不依赖具体的类,而是依赖于接口)

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

接口隔离

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

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

迪米特 | 最少知道

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

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

开闭

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

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

总结

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

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

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

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

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

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

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

以上是关于设计模式设计模式的分类及六大原则的主要内容,如果未能解决你的问题,请参考以下文章

设计模式--分类与六大原则

设计模式设计模式的六大原则与三大分类

设计模式设计模式的六大原则与三大分类

设计模式设计模式的六大原则与三大分类

设计模式六大原则及综述

面向对象六大原则及单例模式