再看三大类设计模式

r囧r小猫 2022-07-15 06:27 114阅读 0赞

** 设计模式概述**

重复遇到的典型问题，描述这些共同问题和解决这些问题的方案 就形成了所谓的模式。面向对象设计时需要考虑 封装性、力度大小、依赖关系、灵活性、可重用性 等。

1、简化并加快快设计

无需从底层做起，重用成功的设计，节约开发时间，提高软件质量。

2、方便开发人员之间的通信

可以更准确地 描述问题 及 问题的解决方案，使解决方案具有一致性。

3、降低风险

4、有助于转到面向对象技术

** 设计模式的历史**

模式分为几个部分：

特定的情景(Context)，指模式在 何种情况下发生作用;

动机(System of Force)，指问题或预期的目标;

解决方案(Solution)，平衡各动机 或解决所阐述问题的 构造或配置。

每个模式描述了一个在某种特定情境下不断重复发生的问题，以及解决该问题解决方案的核心所在。

**模式部分**

特定的情景(Context)，指模式在 何种情况下发生作用;

动机(System of Force)，指问题或预期的目标;

解决方案(Solution)，平衡各动机 或解决所阐述问题的 构造或配置。

每个模式描述了一个在某种特定情境下不断重复发生的问题，以及解决该问题解决方案的核心所在。

![Center][]

**　设计模式的组成元素**

1、模式名，简洁地描述了 模式的本质，可以帮助我们思考。

2、问题或意图，解释了设计问题和问题存在的前因后果，可能描述了特定的设计问题。

3、情景，告诉我们该模式的适用性。

4、动机，描述相关的动机和约束，通常需要对各期望的目标进行有限排序，动机阐明了问题的复杂性，定义了在相互冲突时所采取的各种权衡手段。

5、解决方案，因为模式就像一个模板，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的 抽象描述 和怎样用一个 具有一般意义的 元素组合。

6、示例，帮助读者理解模式的具体使用方法。

7、结果情景，阐述了模式后续状态和副作用。

8、基本原理，解释该模式 如何、为何 能解决当前问题。

9、相关模式，包括 静态的 和 动态的，迁到模式、后续模式、替代模式。

10、已知应用，通常好的模式前面都有一个摘要，提供简短的总结和概述，为模式描绘出一个清晰的图画，提供有关该模式能够解决问题的快速信息。

新技术可能带来的效果持怀疑态度。

模式应该说明它的目标读者，以及对读者有哪些知识要求。

**设计模式的分类**

（记忆方法：五指山，葫芦娃，两条腿，分别对应下面是5,7,11个模式。

创建型：两个工厂为原型，建造单例。

结构型：带组装饰外桥乡\[代组装适外桥享\]，带着一个小组去装饰叫外桥的乡。代理，组合，装饰，适配，外观，桥接，享元

行为型：剩下的都是，别记了）

1、**创建型模式**，对**对象实例化过程的 抽象**，采用抽象类所定义的接口，封装了对象如何创建、组合等信息。

2、**结构型模式**，如何组合已有的类和对象 以及**获得更大的结构**。

3、**行为型模式**，不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述**一组对等的对象怎样互相协作** 完成其中任一对象无法单独完成的任务。

**1、Abstract Factory 模式**

在不指定具体类的情况下，为创建一些列 相关 或 相互依赖的对象提供了接口。

提供了一个可以 确定合适的具体类 的抽象类。

优点：

可以与具体类分开。

更容易在产品系列中转换。

提高了产品间的一致性。

以下情况应该使用 Abstract Factory 模式：

系统独立于产品的 创建、组成、表示。

系统配置成 具有多个产品的 系列。

相关产品对象系列 是共同使用的，而且必须确保这一点。

你希望提供产品的类库，只开放其接口。

**2、Builder 模式**

将复杂对象的 构件与表示 相分离，相同的构造过程可以创建不同的对象，通过只指定对象的 类型和内容。

一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。

优点：

可以对产品内部表示进行改变。

将构造代码与表示代码相分离。

以下情况应该使用 Builder 模式：

算法独立于 组成对象。

构造过程必须允许已构件对象有不同表示。

**　3、Factory Method 模式**

实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。

优点：

代码只处理接口，因此可以使用任何实现了接口的类。

在类中创建对象比直接在客户端创建要更加灵活。

以下情况中，应该使用 Factory Method 模式：

类不能预料它必须创建的对象的类。

类希望其子类指定要创建的对象。

类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。

**　　4、Prototype 模式**

只要将对象类定义成能够复制自身就可以实现。

优点如下：

可以在运行时 添加或删除产品。

通过改变值 指定新对象。

通过改变结构 制定新对象。

减少子类的生成和使用。

可以用类 动态地配置 应用程序。

以下情况中，应该使用Prototype 模式：

运行时，指定需要实例化的类，例如动态载入。

避免构建与产品的类层次结构相似的 工厂类层次结构。

**　5、Singleton 模式**

确保 一个类只有一个实例，并且提供全局访问入口，确保使用这个 实例 所有的对象 使用相同的实例。

优点：

对单个实例的受控访问。

命名空间的减少。

允许改进操作和表示。

允许改变数目的实例。

比类操作更灵活。

结构型模式

**　1、Adapter 模式**

可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。

优点：

允许多个不兼容的对象 进行交互和通信。

提高已有功能的重复使用性。

以下情况，应该使用 Adapter 模式：

要使用已有类，而该类接口与所需的接口并不匹配。

要创建可重用的类，该类可以与 不相关 或 未知类 进行协作。

要在一个 不同于已知对象接口的接口环境中 使用对象。

必须要进行多个源之间的接口转换的时候。

**2、Bridge模式**

将一个复杂的组件 分成两个独立的 但又相关的 继承层次结构：功能性抽象和内部实现。

优点：

接口与实现相分离。

提高了可扩展性。

对客户端隐藏了实现的细节。

以下情况中，应该使用 Bridge 模式：

避免在抽象及其实现之间 存在永久的绑定。

抽象及其实现 可以使用子类进行扩展。

抽象的实现被改动 不用重新编译代码。

**3、Composite 模式**

创建树形层次结构来改变复杂性。

优点：

定义了由 主要对象 和 符合对象 组成的类层次结构。

添加新的组件类型更加简单。

结构的灵活性和可管理性的接口。

以下情况中，应该使用 Composite 模式：

想要表示对象的整个 或者部分的层次结构。

想要客户端能够忽略符合对象和单个对象之间的差异。

结构可以具有任何级别的复杂性，而且是动态的。

**4、Decorator 模式**

不修改对象外观和功能的情况下 添加或删除对象功能。

优点：

比静态继承具有更大的灵活性。

避免了特征装载的类 处于层次结构的 过高级别。

简化了编码。

改进了对象的扩展性。

在以下情况中，应该使用 Decorator 模式：

在单个对象中 动态并且透明地 添加责任，不会影响其他对象。

以后可能要修改的对象中添加责任。

无法通过静态子类化实现扩展时。

**5、Facade 模式**

为子系统中的一组接口 提供了一个统一的接口。更容易使用子系统的高级接口。

优点：

在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。

屏蔽了子系统组件。

提高若耦合度。

将客户端请求转换后 发送给能够处理这些请求的 子系统。

以下情况中，应使用 Facade 模式：

为复杂的子系统提供简单的接口。

客户端和抽象的实现类中 存在许多依赖关系。

想要对子系统进行分层。

**6、Flyweight 模式**

通过共享对象 减少对象数目。

通过共享一个接口来避免使用多个具有相同信息的实例 所带来的开销。

优点：

减少了要处理的对象数目。

如果对象能够持续，可以减少内存和存储设备。

以下情况中，应该使用 Flyweight 模式：

应用程序使用大量的对象。

由于对象数目巨大，导致很高的存储开销。

不依赖于对象的身份。

行为型模式

**1、Chain of Responsibility 模式**

在系统中建立一个链，在首先接收到它的级别处 被处理，或者定位到可以处理它的对象。

优点：

降低了耦合度。

增加面向对象制定责任的 灵活性。

类的集合可以作为一个整体。

以下情况中，应该使用 Chain of Responsibility 模式：

多个对象可以处理一个请求，而其处理器却是未知的。

在不指定确切的 请求接受对象的情况下，向几个对象中的 一个 发送请求。

动态地指定能够处理请求的对象集。

**　2、Command 模式**

在对象中封装了请求。

优点：

将调用操作的对象 与 知道如何完成该操作的对象 相分离。

更容易添加新指令，因为不用修改已有类。

以下情况中，应该使用 Command 模式：

要通过执行的动作 来 参数化对象。

在不同的时间 指定、排序、执行 请求。

必须支持 Undo、日志记录 或 事务。

**　3、Interpreter 模式**

解释定义其语法表示的语言，提供了语句解释器。

优点：

容易修改并扩展语法。

更容易实现语法。

以下情况中，应该使用 Interpreter 模式：

语言的语法比较简单。

效率并不是最主要的问题。

**　　4、Iterator 模式**

为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。

优点：

支持集合的不同遍历。

简化了集合的接口。

以下情况中，应该使用 Iterator 模式：

不开放集合对象内部表示的前提下，访问集合对象内容。

支持集合对象的多重遍历。

为遍历集合中的不同结构 提供了统一的接口。

**　　5、Mediator 模式**

通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间的松耦合度，还可以独立地 改变 其间的交互。

优点：

去除对象间的影响。

简化了对象间协议。

集中化了控制。

由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。

由于不再需要 包含逻辑 来处理组件间的通信，组件变得更加通用。

以下情况中，应该使用 Mediator 模式：

对象集合需要以 一个定义规范但复杂的方式 进行通信。

**　　6、Memento 模式**

保持对象状态的“快照”(snapshot)，对象可以在不向外界公开其内容的情况下 返回到它的最初状态。

优点：

保持封装的完整性。

简化了返回到初始状态所需的操作。

以下情况中，应该使用 Memento 模式：

必须保存对象状态的快照，恢复状态。

**　　7、Observer 模式**

定义了对象间 一到多 的依赖关系，当对象改变状态时，将自动通知 并 更新它所有的依赖对象。

优点：

抽象了主题与 Observer 之间的耦合关系。

支持广播方式通信。

以下情况中，应该使用 Observer 模式：

对一个对象的修改 涉及对其他对象的修改，而且不知道有多少对象 需要进行相应修改。

对象应该能够 在不同假设对象标识的前提下 通知其它对象。

**　　8、State 模式**

对象在内部状态变化时，变更其行为，并且修改其类。

优点：

针对不同状态来划分行为，使状态转换显式进行。

**　　9、Strategy 模式**

定义了一组能够用来表示 可能行为集合的类。这些行为 可以在应用程序中使用，来修改应用程序功能。

优点：

另一种子类化方法。

在类自身中定义了 每一个行为，减少了条件语句。

更容易扩展模型。

以下情况中，应该使用 Strategy 模式：

许多相关类 只是在行为方面有所区别。

需要算法的不同变体。

算法使用客户端未知的数据。

**　　10、Template Method 模式**

不重写方法的前提下 允许 子类重载部分方法 的方法。

将一些步骤由子类实现。

优点：代码重用的基础技术。

以下情况中，应该使用 Template Method 模式：

一次实现算法的不变部分，子类实现算法的可变行为。

**　　11、Visitor 模式**

不改变操作元素的类 的前提下 定义一个新操作。

优点：

容易添加新操作。

集中相关 排除不相关 操作。

以下情况中，应该使用 Visitor 模式：

包含许多具有不同接口的对象类，并且想要对这些 依赖具体类的对象进行操作。

定义对象结构的类很少被修改，但想要在此结构上定义新的操作。

总结：

再次学习设计模式，思想是精髓，如何做到系统的高内聚低耦合，这些设计模式只是提供了一方面的想法。更多的面向对象的思想，需要在代码编写中体现，设计模式是编码的艺术。

[Center]: /images/20220715/f272564226744a97bbaba4897aee580c.png

再看三大类设计模式

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关从《大话设计模式》看JDK及框架中常用的设计模式（三）

相关设计模式之基础：UML类图怎么看？

相关再刷设计模式概述

相关 [设计模式] 再识责任链模式

相关设计模式的五大原则(三)

相关设计模式——三大工厂模式

相关再看三大类设计模式

相关【设计模式】全局观之为什么分三大类

相关【菜鸟学习设计模式】——分哪三大类？

相关设计模式三大类别