设计模式

2024-02-28 16:37:22   0  举报





仅支持查看

AI智能生成

设计模式是一种用于设计高质量的软件系统的方法论。它是一种可重用、可扩展的解决方案，用于解决软件设计中的问题。常见的设计模式包括工厂模式、观察者模式、策略模式、装饰器模式等。每种模式都有其特定的应用场景，例如工厂模式用于创建对象，观察者模式用于事件通知，策略模式用于算法切换，装饰器模式用于增强对象功能等。使用设计模式可以提高代码的可维护性、可扩展性和可重用性，从而提高软件开发效率和软件质量。

其他技术

作者其他创作

大纲/内容

设计模式概述

常用标准

1.可维护性

2.可读性

3.可扩展性

4.灵活性

5.简介性

6.可复用性

7.可测试性

编程方法论

1.面向对象（基础）

2.设计原则（指导方针）

- 单一职责原则
- 开闭原则
- 里氏代换原则
- 依赖倒转原则
- 接口隔离原则
- 迪米特法则

3.设计模式（设计原则的具体实现）

常见23种设计模式

4.编程规范（提高代码可读性）

5.重构（面向对象设计思想、设计原则、设计模式、编码规范的融合贯通）

设计模式分类

创建型(Creational)：提供创建对象的机制，提升已有代码的灵活性和可复用性

单例模式

工厂模式（工厂方法和抽象工厂）

建造者模式

原型模式（不常用）

结构型(Structural)：介绍如何将对象和类组装成较大的结构，并同时保持结构的灵活和高效

代理模式

桥接模式

装饰者模式

适配器模式

门面模式（以下均不常用）

组合模式

享元模式

行为型(Behavioral)：负责对象间的高效沟通和职责传递委派

观察者模式

模板模式

策略模式

职责链模式

迭代器模式

状态模式

访问者模式（以下均不常用）

备忘录模式

命令模式

解释器模式

中介模式

UML类图

作用

在软件工程中，类图是一种静态的结构图，描述了系统的类的集合，类的属性和类之间的关系，可以简化了大家对系统的理解

表示法

在UML类图中表示具体类

具体类在类图中用矩形框表示，矩形框分为三层：第一层是类名字。第二层是类的成员变量；第三层是类的方法。成员变量以及方法前的访问修饰符用符号来表示：
- “+” 表示 `public`；
- “-” 表示 `private`；
- “#” 表示 `protected`；
- 不带符号表示 `default`。

在UML类图中表示抽象类

抽象类在UML类图中同样用矩形框表示，但是抽象类的类名以及抽象方法的名字都用斜体字表示，如图所示。

在UML类图中表示接口

接口在类图中也是用矩形框表示，但是与类的表示法不同的是，接口在类图中的第一层顶端用构造型 <<interface>>表示，下面是接口的名字，第二层是方法。

在类图中表示关系

类和类、类和接口、接口和接口之间存在一定关系，UML类图中一般会有连线指明它们之间的关系。
关系共有六种类型 ,如下图:

实现关系：汽车和船实现了交通工具，其类图:

泛化关系：Student 类和 Teacher 类都是 Person 类的子类

关联关系

单向关联

双向关联

所谓的双向关联就是双方各自持有对方类型的成员变量。

自关联

聚合关系

聚合关系是关联关系的一种，表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但是B对象不是A对象的一部分
在代码中: 比如A 类对象包含 B 类对象，B 类对象的生命周期可以不依赖 A 类对象的生命周期，也就是说可以单独销毁 A 类对象而不影响 B 对象

组合关系

组合关系是一种强‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的声明周期一样
在代码中: 比如A 类对象包含 B 类对象，B 类对象的生命周期依赖A 类对象的生命周期，B 类对象不可以单独存在

依赖关系

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。
司机和汽车的关系图，司机驾驶汽车：

六大设计原则

单一职责原则（Single Responsibitity Principle）

一个类只负责完成一个职责或者功能
也就是说在类的设计中我们不要设计大而全的类,而是要设计粒度小、功能单一的类

如何判断一个类的职责是否单一?

- 类中的代码行数、函数、或者属性过多；
- 类依赖的其他类过多
- 私有方法过多
- 类中大量的方法都是集中操作类中的几个属性

开放封闭原则（Open Close Principle）
最核心的目标

对扩展开放，对修改关闭

优点：
1. 新老逻辑解耦，需求发生改变不会影响老业务的逻辑
2. 改动成本最小，只需要追加新逻辑，不需要改的老逻辑
3. 提供代码的稳定性和可扩展性

顶层设计思维：
1.抽象意识
2.封装意识
3.扩展意识

里氏替换原则（Liskov Substitution Principle）

利用面向对象语言所支持的多态特性，同一个行为具有多个不同表现形式或形态的能力；
即：在不了解派生类的情况下，仅通过接口或基类的方法，即可清楚的知道方法的行为

举例：调用一个还款方式的接口，底下有不同还款方式的实现方法，即生成期供和本金，外壳不变，里面实现不一样

接口隔离原则（Interface Segregation Principle）

一个类对另一个类的依赖应该建立在最小的接口上
通俗解释：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则与单一职责原则的区别：
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
- 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
- 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

给userservice接口新增一个删除的方法，不能直接在该接口上加，避免被外围系统直接调用，而是另外开一个接口，去实现这个删除功能，供后台管理系统使用，这里即两个不同的管理系统用不同的接口

优势：
1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
3. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码

依赖倒置原则（Dependence Inversion Principle）

指的是设计代码架构时，高层代码不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。因为细节是多变的，而抽象层相对稳定

区别和联系

依赖倒置原则：是一种通用的软件设计原则，主要用来知道框架层面的设计

控制反转：控制反转和依赖倒置有一些相似，他是一种框架设计常用的模式
，并不是具体的方法

依赖注入：是实现控制反转的一个手段，是一种具体的编码技巧

迪米特法则（Law Of Demter）

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口
类似于找经纪人或代理人去实现服务与服务之间的调用

总结

单一职责原则

概念

一个类只负责完成一个职责或者功能