【软考中级-软件设计师笔记】设计模式

1. 分类

2. 创建型模式

2.1 简单工厂模式

不属于23种模式之一，只是先引入
就是通过不同参数，用static方法创建不同的对象
比如
父类是抽象类饺子，韭菜馅类和三鲜馅类继承父类，然后创建的时候用一个class Factory来传递类型，来选择实例化不同的类，比如Factory.get(饺子馅)-> class 饺子

但是这样不满足开闭原则，即对扩展开放，对修改关闭

2.2 工厂模式

满足开闭原则，这时候父类和工厂首先都是借口，子类都需要实现

工厂模式的意图：
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的
实例化延迟到其子类。

抽象工厂模式

就是一个工厂可以创建更多产品，然后模式就是都是集成接口或者抽象类

适用于：

• 一个系统要独立于它的产品的创建、组合和表示时。
• 一个系统要由多个产品系列中的一个来配时。
• 当要强调一系列相关的产品对象的设计以便进行联合使用时。
• 当提供一个产品类库，只想显示它们的接口而不是实现时。

例题：

1. 
   解析：区分是工厂还是抽象工厂：就看工厂能创建多少产品。多个就是抽象。选C
   44题，D说的是结构性模式

2.3 生成器模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

逐一构建每个part

比如说，director是服务员，builder是抽象的一个套餐，concreteBuilder是具体的套餐。
相当于产品有不同的part，然后不同的builder有具体的装配part的方式

适用场景：

• 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
• 当构造过程必须允许被构造的对象有不同的表示时。

例题：
1.

解析：ACA。第二问，使用Builder的是waiter。只有工厂是创建型类，其他都是创建型对象。

2.4 原型模式

用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象

适用于：

• 当一个系统应该独立于它的产品创建、构成和表示时。
• 当要实例化的类是在运行时刻指定时，例如，通过动态装载。
• 为了避免创建一个与产品类层次平行的工厂类层次时。
• 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们，可能比每次用合适的状态手工实例化该类更方便一些。

2.5 单例模式

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

适用于：

• 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时
• 当这个唯一实例应该是通过子类化可扩展的，并且客户无须更改代码就能使用一个扩展的实例时。

3. 结构型设计模式

3.1 适配器模式

将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

Adapter就是继承USB类，然后重写Request函数，调用的是Type-C的request

适用：

• 想使用一个已经存在的类，而它的接口不符合要求。
• 想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。
• (仅适用于对象适配器)想使用一个已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。

3.2 桥接模式

将抽象部分与其实现部分分离，使它们都可以独立地变化

说白了就是解耦合，模块化。比如说，有产品类，和颜色类。每个产品有一个颜色，中间的桥接就是连接产品和颜色的桥。

适用于：

• 不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如，这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。
• 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这是 Bridge 模式使得开发者可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
• 对一个抽象的实现部分的修改应对客户不产生影响，即客户代码不必重新编译。
• (C++)想对客户完全隐藏抽象的实现部分。
• 有许多类要生成的类层次结构。
• 想在多个对象间共享实现(可能使用引用计数)，但同时要求客户并不知道这一点。

3.3 组合模式

部分-整体的层次结构

像n叉树，非叶子节点一般定义operation、add、remove、getChild方法，叶子节点只有Operation方法。
比如说，文件夹里面可以包含文件和文件夹，文件夹可以用增加、删除、获得当前文件和文件夹方法。文件只有获得文件方法。

适用于：

• 想表示对象的部分-整体层次结构。
• 希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。（比如把文件和文件夹统一使用）

3.4 装饰器模式

动态地给一个对象添加额外的职责，比如父类是人，子类是学生，则添加学习的职责。
可以结合Python装饰器的功能去理解。

一般上图的Component和Decorator都是abstract class，然后再具体实现

适用于：

• 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
• 处理那些可以撤销的职责。
• 当不能采用生成子类的方式进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是，由于类定义被隐藏，或类定义不能用于生成子类。

3.5 外观模式

为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

就像一个网站，里面有各种各样的子模块。将客户请求代理给子系统（比如注册登录模块），

适用于：

• 为一个复杂的子系统提供简单接口时
• 客户程序与抽象类的实现部分之间存在着很大的依赖性
• 当需要构建一个层次结构的子系统时，使用外观模式定义子系统中每层的入口点

3.6 享元模式

运用共享技术有效地支持大量细粒度的对象
说白了就是提取共性以减少内存

适用于：

• 一个程序上使用了大量的对象，造成很大存储开销
• 对象的大多数状态可以转变为外部状态
• 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象

比如说，在FlyweightFactory里面只维护几个对象，然后维护键值对，根据key寻找对象并修改，否则才创建。比如下五子棋，自始至终就只有一个白棋/黑棋对象，只不过每次修改内部状态，例如xy坐标

3.7 代理模式

为其他对象提供一种代理以控制对这个对象的访问

适用于：
在需要比较通用和复杂的对象指针代替简单的指针的时候

4. 行为型设计模式

4.1 责任链模式

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

理解成学生要请假，然后找辅导员等等，踢皮球

适用于：

• 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定
• 想在不明确指定接收者的情况下向多个对象中的一个提交一个诸求
• 可处理一个请求的对象集合应被动态指定。

4.2 命令模式

将一个请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。

说白了就是把命令放在了一个更“上层”的位置

适用于：

• 抽象出待执行的动作以参数化某对象
• 在不同时刻指定
• 支持取消操作
• 支持修改日志
• 用构建在原语操作上的高层操作构造一个系统

4.3 解释器模式

4.4 迭代器模式

提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。
想想C++ Java的iterator

适用于：

• 访问聚合对象的内容而无需内部表示
• 支持多种遍历
• 为遍历不同聚合结构提供统一的接口

4.5 中介者模式

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而
使其耦合松散，而且可以独立地改变它们之间的交互.

有点像路由器连接网络，路由器充当中介封装连接关系

适用于：

• 一组对象以定义良好但是复杂的方式进行通信，产生的相互依赖关系结构混乱且难以理解。
• 一个对象引用其他很多对象并且直接与这些对象通信，导致难以复用该对象。
• 想定制一个分布在多个类中的行为，而又不想生成太多的子类。

4.6 备忘录模式

在不破坏封装性的前提下捕获一个对象的内部状态，这样以后就可以将对象恢复到原先保存的状态。并在对象之外保存这个状态。

适用于：

• 必须保存一个对象在某一个时刻的(部分)状态，这样以后需要时它才能恢复到先前的状态。
• 如果一个用接口来让其他对象直接得到这些状态将会暴露对象的实现细节并破坏对象的封装性。

4.7 观察者模式

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

比如说，up和粉丝的关系

适用于：

• 当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。
• 当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变时。
• 当一个对象必须通知其他对象，而它又不能假定其他对象是谁，即不希望这些对象是紧耦合的。

4.8 状态模式

允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

就是一个状态对应一个行为，比如贩卖机的有货和无货状态决定行为

适用于：

• 一个对象的行为决定于它的状态，并且它必须在运行时刻根据状态改变它的行为。
• 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态常用一个或多个枚举常量表示。

4.9 策略模式

定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。此模式使得算法可以独立于使用它们的客户而变化。

就是用不同的策略去应对环境需求

适用于：

• 许多相关的类仅仅是行为有异。
• 需要使用一个算法的不同变体。
• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
• 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，将相关的条件分支移入它们各自的 Strategy 类中，以代替这些条件语句。

4.10 模板方法模式

定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

这个很常用，就是比较普通的抽象和继承

适用于：

• 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
• 各子类中公共的行为应被提取出来并集中到一个公共父类中，以避免代码重复。
• 控制子类扩展：模板方法在特定点调用“hook”操作(默认行为，子类可以在必要时进行重定义扩展)，这就只允许在这些点进行扩展。

4.11 访问者模式

表示一个作用于某对象结构中的各元素的操作。它允许在不改变各元素的类的前提下定义作用于这些元素的新操作。

说白了就是给访问者传一个对象的引用，允许通过接口做一定的操作。当然，类里面也要定义访问者的行为。类通过accept操作来执行访问者里面预定义好的操作。

适用于：

• 一个对象结构包含很多类对象，它们有不同的接口，而用户想对这些对象实施一些依赖于其具体类的操作。
• 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而又想要避免这些操作“污染”这些对象的类。
• 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。