当前位置：首页 > news >正文

设计模式-笔记

news 文章来源：https://blog.csdn.net/qq_44482764/article/details/121728410 2024/9/20 15:26:36

文章目录

- - 七大原则
  - 单例模式
  - 桥模式 bridge
  - 观察者模式 observer
  - 责任链模式 Chain of Responsibility
  - 命令模式 Command
  - 迭代器模式 Iterator
  - 中介者模式 Mediator
  - 享元模式 Flyweight Pattern
  - 组合模式 composite
  - 装饰模式 Decorator
  - 外观模式 Facade
  - - - 简单工厂模式
      - 工厂方法模式
      - 工厂抽象模式

七大原则

开闭原则（Open Close Principle）

对扩展开放，对更改关闭
保证以前代码的准确性，使开发者更专注于新扩展的代码上

单一职责原则（Single Responsibility Principle）

一个类只负责一个功能领域的职责
降低类的复杂度，当修改一个功能时，降低对其他功能的影响，提供类的可读性

里氏替换原则（Liskov Substitution Principle）

任何基类出现的地方，子类一定可以出现
在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象，开闭原则实现的手段之一

依赖倒转原则（Dependence Inversion Principle）

针对接口编程，抽象不依赖于细节，细节应依赖于抽象
- 多数情况下，开闭原则，里氏替换原则，依赖倒转原则会同时出现，开闭原则是目标，里氏替换原则是基础，依赖倒转是手段。

接口隔离原则（Interface Segregation Principle）

使用多个专门的接口，不使用单一的总接口
- 当一个接口太大时，我们需要把他拆分成更小的接口，但不能违反单一职责原则，每个接口应该承担一种相对独立的角色，不该干的事情不干，该干的事情都要干。

迪米特法则（Law Of Demeter）

一个实体应当尽量少的与其他实体发生相互作用，也就最少知道原则，一个对象尽量让其它对象保持最少的了解
- 应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。

合成复用原则（Composite Reuse Principle）

尽量使用组合而非继承
- 就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过这些对象的委派达到复用已有功能的目的

单例模式

只涉及一个负责实例化自身的类，以确保它创建的实例不会超过一个，并且提供一个全局访问控制点

每个类在内存中只有一个实例
实例必须由该类创建
一个实例必须被整个系统访问

桥模式 bridge

从现实中分离抽象，这样两者可以独立变化
在这里插入图片描述 Abstraction：抽象定义了抽象接口
RefinedAbstraction：使用对Implementor类型的对象的引用来实现Abstraction接口
Implementor：定义实现类的接口，这个接口不需要直接对应Abstraction接口，可以有很大不同

例：现在我们需要供应三种尺寸的蜡笔(大、中、小)，有五种颜色(红、绿、蓝、白、黑)。根据桥状图案，设计一个系统来制作彩色蜡笔。

观察者模式 observer

定义对象间的一种一对多的依赖关系，以便当一个对象的状态改变时，所有依赖它的对象都得到通知并自动刷新
在这里插入图片描述

在这里插入图片描述

责任链模式 Chain of Responsibility

在编写代码过程中，经常会发生由一个对象生成的事件需要另一个对象处理的情况，有时候还会被拒绝访问需要处理的对象
责任链设计模式允许对象发送命令，但不知道哪个对象将接收和处理它。请求从一个对象发送到另一个对象，使他们成为链的一部分，这个链中的每个对象都可以处理/传递命令。
为解除请求的发送者和接受者之间的解耦，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它

学生需要申请奖学金，并提交申请表，该申请表需要一层层批准：辅导员，系主任，院长…

在这里插入图片描述

命令模式 Command

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队货记录请求日志，以及支持可取消的操作

将请求封装在对象中
允许参数化具有不同请求的客户端
允许将请求保存在队列中
命令在发送方和接收方之间解耦

在这里插入图片描述

迭代器模式 Iterator

提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象内部表示
在这里插入图片描述

在这里插入图片描述

中介者模式 Mediator

用一个中介对象来封装一系列对象的交互；中介对象使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互
在这里插入图片描述

享元模式 Flyweight Pattern

运用共享技术有效地支持大量细粒度的对象。

适用性
当以下所有的条件都满足时，可以考虑使用享元模式：

一个应用程序使用了大量的对象。
完全由于使用大量的对象，造成很大的存储开销。
对象的大多数状态都可变为外部状态。
如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。
应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。

满足以上的这些条件的系统可以使用享元对象。

最后，使用享元模式需要维护一个记录了系统已有的所有享元的表，而这需要耗费资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。
在这里插入图片描述

组合模式 composite

将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复合对象使用具有一致性
在这里插入图片描述

装饰模式 Decorator

动态地给一个对象添加一些额外的功能

动态、透明的方式给单个对象添加职责。
如果不适合适用子类来进行扩展的时候，可以考虑适用装饰模式。
避免子类数目爆炸性增长

在这里插入图片描述

Component: 定义一个对象接口,可以给这些对象动态地添加职责.
ConcreteComponent: 定义一个对象,可以给这个对象添加职责.
Decorator: 持有一个指向Component对象的引用,并定义一个与Component的接口一致的接口.
ConcreteComponent: 向组件添加职责

在这里插入图片描述

外观模式 Facade

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
在这里插入图片描述

在这里插入图片描述

简单工厂模式

用户不需要知道产品类别，只需要提供一个参数
让客户类永远接触不到产品类，只是让用户知道抽象或接口类
在这里插入图片描述

工厂方法模式

简单工厂模式的问题就是：类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改
工厂方法模式添加了concrete factory和abstract factory——遵循open-close原则和dependency reverse 原则
工厂是一个抽象creator，只是要求具体的工厂生产一个产品

如下例：
假如增加其他品牌鼠标，工厂类需要修改，如何解决？就用到工厂方法模式，创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
在这里插入图片描述

工厂抽象模式

抽象工厂提供了创建一系列相关对象的接口，而无需显式地指定它们的类
factory method 处理来自多个生产商的一组产品
factory abstract 处理来自多个生产商的多组产品
抽象工厂模式中我们可以定义实现不止一个接口，一个工厂也可以生成不止一个产品类，抽象工厂模式较好的实现了“开放-封闭”原则，是三个模式中较为抽象，并具一般性的模式。我们在使用中要注意使用抽象工厂模式的条件
例：新增一个键盘产品类
在这里插入图片描述

文章目录

七大原则

单例模式

桥模式 bridge

观察者模式 observer

责任链模式 Chain of Responsibility

命令模式 Command

迭代器模式 Iterator

中介者模式 Mediator

享元模式 Flyweight Pattern

组合模式 composite

装饰模式 Decorator

外观模式 Facade

简单工厂模式

工厂方法模式

工厂抽象模式

相关文章：