设计模式【持续更新中】-CSDN博客

本文链接：https://blog.csdn.net/qq_64225133/article/details/130757919

提高代码的可维护性，可扩展性，重用性，灵活性

实现高内聚，低耦合

一、七大设计原则介绍

0.七大设计原则

单一职责原则【对类的要求】
接口隔离原则【对接口的要求】
依赖倒转原则【对方法的要求】
里氏替换原则【对继承的要求】
开闭原则【对编程的要求】
迪米特法则【类与类的要求】
合成复用原则

1.单一职责原则

基本介绍：对于类来说，一个类应该只负责一项职责

解释：如果A负责两个不同职责：职责1、职责2。当职责1需求改变，需要更改A是，可能造成职责2执行错误。所以需要将A类分解

单一职责注意事项和细节
1. 降低类的复杂度，一个类只负责一项职责
2. 提高类的可读性，可维护性
3. 降低变更引起的风险
4. 通常情况下，我们应当遵循单一职责原则，只有逻辑足够简单的情况下，才可以违反单一职责原则。

2.接口隔离原则

基本介绍：客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

案例解释：一个接口有5个方法，B类实现这个接口，所以需要实现这5个方法。A需要使用接口1、2、3方法，所以需要使用B（通过多态），但是4、5方法没有用。所以4，5方法对于A来说是多余的。因此违反了接口隔离原则。

隔离原则的处理方式：将接口拆分为几个独立的接口，类A和其他类分别与他们需要的接口建立依赖关系，这样就不会存在多余的方法

3.依赖倒转原则

基本介绍：

高层模块不应该依赖底层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转的核心思想是面向接口编程

设计理念：相对于细节的多变性，抽象的东西要稳定。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。【在java中，抽象指的是接口或抽象类，细节就是具体的实现类】

人话就是方法里面最好传进一个接口，不要传具体类，因为不方便后面功能的扩展

3.1 案例

有一个Person类，这个类有一个功能可以实现接收信息的功能（邮件、微信等）

初级思路

创建一个Person类，有receive方法，用来接收邮件。

然后创建邮件类。

调用receive的方法的时候将邮件类传进去
问题分析

这样我们的这个人的receive方法只能接收邮件，如果需要接收其他信息【微信】，Person类还需要增加响应的方法
解决思路

写一个接口，接口有发信息的方法。

然后让Email类实现接口的方法。

Person的receive方法的参数设置为接口。

这样Email可以通过多态传进来，后续有其他设备发信息也可以接收进来

3.2 依赖传递的方式(三种方式)

3.2.1 通过接口实现依赖

接口里面中方法的参数是一个接口

3.2.2 通过构造方法传递依赖

构造方法里面的参数赋值给类里面的接口属性

3.2.3 通过set方法传递

通过set方法给接口属性赋值

4 里氏替换原则

继承的思考：继承在带来便利性的同时，也带来了弊端。

继承会给成需带来侵入性
程序的可移植性降低
增加对象间的耦合关系【父类变化会影响子类的功能】

里氏替换原则基本介绍：使用父类实现的功能，在替换为子类时，程序的功能没有变化

为了实现上述条件，子类尽量不要重写父类方法。可以通过聚合、组合、依赖来解决问题

案例：

A类有一个方法，B类继承了A类，想自己定义一个方法，但是一不小心跟父类A的某个方法重名了。但是B在使用的时候还是想使用A的原方法，这个时候实现的功能就不再是A的原本功能了
1. 案例展示
2. 问题分析
  
  A类只有一个方法所以问题不明显。
  
  如果A类有很多方法，并且AB类有共同的方法，那么可以创建一个父类Base类。
  
  然后AB共同实现它，那么他俩就有共同的方法
  
  如果B需要调用A的特有方法，可以自己创建一个A对象

5.开闭原则

开闭原则是编程中最基本，最重要的原则

基本介绍：

模块和函数应该对扩展开放（提供方），对修改关闭（使用方）。用抽象构建框架，用实现扩展细节
当程序需要提供新功能时，尽量通过扩展来实现变化，而不是通过修改已有的代码

人话就是：

当我的程序修改功能的时候，使用者的代码没有发生变化
如果需要增加功能，尽量不要修改原有的代码，而是增加新代码

解决方法：使用抽象方法，用户的方法里面传进去的是方法。我们程序员进行扩展的时候实现抽象方法，这样可以通过多态调用扩展的方法【可以理解为依赖倒转】

6.迪米特法则

又叫最少知道原则

基本介绍

一个对象应该对其他对象保持最少的了解
类与类关系越密切，耦合度越大
迪米特法则又叫知道最少原则。即一个类对自己依赖的类知道的越少越好，也就是说对于以来的类不管多么复杂，都尽量将逻辑封装在类的内部。对外提供public方法，不对外泄露任何信息
只与直接的朋友通信【直接的朋友：出现在成员变量、方法参数、方法返回值中的类】

案例分析：

这个案例中直接朋友CollegeManager、Employee【上面的方法中是成员变量】，间接朋友CollegeEmployee。所以违背了迪米特法则

改进方案：可以把获取学院员工的代码放到与CollegeEmployee是直接朋友的类中

这个案例中CollegeManager是CollegeEmployee的直接朋友，CollegeManager是上面那个图的直接朋友，所以可以把获取员工的方法放到CollegeManager里面，然后上面那个类直接调用CollegeManager的方法就好了

7.合成复用原则

基本介绍：原则是尽量使用合成/聚合的方式，而不是使用继承

例子：如果A、B是单独的两个类，如果让B单纯使用A的方法，那么如果使用继承会让耦合性很大。所以可以让B中有一个属性A，然后通过set方法传进来，这就叫聚合。或者B写一个方法，参数中是传进A的对象。或者直接在B中new一个A

聚合/合成会在UML类图介绍

二、UML类图

通过符号表示类与类之间的关系

箭头指向父类和被引用的类

聚合：通过set方法设置对象属性
组合：一个类中new了另一个类

1.需要的符号

2.工具

方法一：安装一个插件

方法二：idea中File—>new—>Diagram---->Java Class Diagram

3.类之间的关系

依赖、泛化(继承)、实现、关联、聚合、组合

3.1 依赖

只要在类中用到了对方，那么他们就存在依赖关系

例如：成员属性、返回类型、方法的参数类型、方法中使用到的

案例：

PersonServiceBean和PersonDao、Person、IDCard、Department存在依赖关系
类图

3.2 泛化

泛化就是继承关系，是依赖关系的特例

案例

PersonSErviceBean继承了Dapsupport，所以存在泛化关系
类图

3.3 实现

A类实现了B接口，他也是依赖关系的特例

案例
类图

3.4 关联

是类与类之间的联系，是依赖关系的特例

单项一对一关系：人和身份证号，人类里面有身份证类属性，身份证类中没有人类（我中有你，你中无我是单向）

双向一对一关系：人和身份证号，人类里面有身份证类属性，身份证类中也有人类（我中有你，你中有我是双向）

3.5 聚合

表示的是整体和部分是否可以分开。

聚合关系是关联关系的特例

一般是方法的属性对象，没有new

存在方向性：A聚合B，还是B聚合A

存在多重性：只聚合一个，还是聚合多个

例如：笔记本中外接键盘和外接鼠标是否可以分开，如果可以分开那么鼠标、键盘和笔记本就是聚合关系

人和手机的关系，人没有了手机还可以活

案例
类图

3.6 组合

如果上面聚合的案例中不可分离，那么就是组合关系

一般是类中直接new了

是关联关系的特例

例如：台式电脑和cpu的关系、人和头的关系

案例

因为new一个电脑，里面的鼠标和键盘也会new
类图

三、设计模式概述（23种）

创建型模式：

单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
结构性模式：

适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
行为型模式：

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

四、设计模式详解

1.单例模式

介绍：就是采取一定的方法保证在整个软件系统中，对某个类只能存在一个对象实例，并且该类提供一个取得其对象实例的方法（静态方法）

单例模式有八种方式

1.1 饿汉式(静态常量)【可以用】

基本步骤：

构造器私有化（防止被直接new出来）
类的内部创建对象
向外暴露一个静态的公共方法

优点：写法简单，类装载的时候就完成了实例化，避免了线程同步问题

缺点：在类装载的时候就完成了实例化，没有达到懒加载的效果。如果从开始就没使用过这个实例，就会造成内存的浪费

结论：这种单例模式可用，但是可能造成内存浪费