设计模式-（通俗细致讲解）定义&&目的、分类、原则

机智小袁

已于 2023-06-18 21:40:15 修改

阅读量585

点赞数 1

分类专栏： # 设计模式文章标签：设计模式

于 2023-04-02 17:43:51 首次发布

本文链接：https://blog.csdn.net/wangdawei_/article/details/129910441

版权

设计模式专栏收录该内容

5 篇文章 0 订阅

订阅专栏

设计模式是前辈们对代码开发经验的总结，旨在提高代码的可复用性、可维护性、可读性和安全性。主要分为创建型、结构型和行为型模式，每种模式都有其特定的解决思路。设计的七大原则包括开闭原则、单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则，这些原则指导我们编写高质量、低耦合的代码。

摘要由CSDN通过智能技术生成

什么是设计模式？

定义&&目的

设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。其最最本质的目的是为了解耦。让我们写出高内聚，低耦合的代码。

高内聚

高内聚就是指，自己只做职责之内的事情，也可以理解为专业的事交给专业的人去做。
比如：下单模块，支付模块。根据高内聚的要求就应该每个模块只做自己的工作，下单模块完成下单操作后，要进行支付了，此时应该是去调用支付模块提供的接口而不是由下单模块再去写一遍支付逻辑。这就是高内聚！
如何实现高内聚呢？
在这里插入图片描述

低耦合

耦合性是指软件系统各模块之间相互紧密联系程度的一种度量。
在这里插入图片描述
往往高内聚和低耦合是组合出现的，低内聚和高耦合是组合出现的。
举例：你要写一个程序用于操作订单和操作库存代码如下：

/**
* 以下为伪代码
* 在下面的代码中既做了订单的新增保存，又做了库存的操作。
* 导致该函数具有了低内聚（因为内部两部分代码并没有什么直接联系）
* 又导致该函数是高耦合的（因为他让订单和库存的操作高度耦合在了一起）
*
* 此时如果要对订单或者库存的操作流程进行一定修改，就会导致在这个函数修改了后
* 有可能会对另外一个操作造成一定未知影响。
*/
public void opOrderAndStock(String goodsNo,int num){
	//生产订单信息
	Order order = new Order(goodsNo,num);
	//保存订单数据
	orderMapper.saveOrder(order);
	//记录订单操作日志
	orderOperate.saveOp(userId,order,"新增了订单");
	//减少库存
	stockMapper.update(goodsNo,num);
	//记录库存日志,记录是那个订单改变了那个商品的多少库存。
	stockOperate.saveOp(userId,goodsNo,num,order.getOrderNo,"减少了库存");
}

改造：

/**
* 操作库存
*/
public void opStock(String orderNo,goodsNo,int num){
	//减少库存
	stockMapper.update(goodsNo,num);
	//记录库存日志,记录是那个订单改变了那个商品的多少库存。
	stockOperate.saveOp(userId,goodsNo,num,order.getOrderNo,"减少了库存");
}
/**
* 操作订单和库存
*/
public void opOrder(String goodsNo,int num){
	//生产订单信息
	Order order = new Order(goodsNo,num);
	//保存订单数据
	orderMapper.saveOrder(order);
	//记录订单操作日志
	orderOperate.saveOp(userId,order,"新增了订单");
	//操作库存
	opStock(order.getOrderNo,goodsNo,num);
}

高内聚和低耦合的目的是为了实现解耦，本质上就是让代码各司其职，互不干扰。

重点：设计模式的目的是解耦！！！
重点：设计模式的目的是解耦！！！
重点：设计模式的目的是解耦！！！

解耦的目的：“提高代码可复用性、可维护性、可读性、稳健性以及安全性！！！”
解耦的目的：“提高代码可复用性、可维护性、可读性、稳健性以及安全性！！！”
解耦的目的：“提高代码可复用性、可维护性、可读性、稳健性以及安全性！！！”

在学习设计模式的时候一定要时刻谨记设计模式的目的！！！

只有时刻谨记设计模式的目的才能弄懂他每个设计模式为什么有存在的意义，为什么要这样写。

设计模式分类

创建型模式

创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关系创建对象过程中的逻辑。

简单工厂模式（Simple Factory）:简单工厂模式不是GoF总结出来的23种设计模式之一
工厂方法模式（Factory Method）
抽象工厂模式（Abstract Factory）
创建者模式（Builder）
原型模式（Prototype）
单例模式（Singleton）

结构型模式

结构型模式是为解决怎样组装现有的类，设计它们的交互方式。例如：扩展性（外观、组成、代理、装饰）、封装（适配器、桥接）。因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。

外观模式/门面模式（Facade门面模式）
适配器模式（Adapter）
代理模式（Proxy）
装饰模式（Decorator）
桥梁模式/桥接模式（Bridge）
组合模式（Composite）
享元模式（Flyweight）

行为型模式

行为模式刻划了在程序运行时难以跟踪的复杂的控制流，进一步可分为行为类模式和行为对象模式。
行为类模式使用继承机制在类间分派行为。
行为对象模式使用对象聚合来分配行为。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任何一个对象都无法单独完成的任务。

模板方法模式（Template Method）
观察者模式（Observer）
状态模式（State）
策略模式（Strategy）
职责链模式（Chain of Responsibility）
命令模式（Command）
访问者模式（Visitor）
调停者模式（Mediator）
备忘录模式（Memento）
迭代器模式（Iterator）
解释器模式（Interpreter）

三者之间的区别和联系

创建型模式提供生存环境，结构型模式提供生存理由，行为型模式提供如何生存。

创建型模式为其他两种模式使用提供了环境。
结构型模式侧重于接口的使用，它做的一切工作都是对象或是类之间的交互，提供一个门。
行为型模式顾名思义，侧重于具体行为，所以概念中才会出现职责分配和算法通信等内容。

设计模式七大原则

在这里插入图片描述
解释：

1.开闭原则（Open Closed Principle）

最基础、最重要的设计原则

一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。

在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。

想要达到这样的效果，我们需要使用接口和抽象类等。

2.单一职责原则（Single Responsibility Principle）

对于类来说，即一个类应该只负责一项职责。如果A类负责两个不同的职责：职责1、职责2。当职责1发生变化而改变A时，可能会对职责2造成影响使职责2运行错误，所以需要将类A的粒度分解为A1、A2。
如果在类中没有满足单一职责原则，在一个类的方法中遵守单一职责原则也是可以的(交通工具)
标准的单一职责原则，是在类的级别上进行拆分，而不是方法级别。
通常情况下，我们要遵守单一职责原则，只有当逻辑足够简单，才可以在代码级别违反单一职责原则；只有类中的方法数量足够少，才可以在方法级别保持单一职责原则。
优秀的代码中使用类来区分多个分支，而不使用 if…else if()…else(耦合度高)

3.里氏替换原则（Liskov Substitution Principle）

问题：
使用继承的时候，父类会对子类进行约束。并且如果父类中的方法发生改变的时候，可能会对所有的子类造成影响。
里氏代换原则：
里氏代换原则是对“开-闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。
解决方案：
原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代。