7.3.1 设计模式的要素
“每一个模式描述了一个在我们附近不停重复发生的问题，以及该问题的解决方案的焦点。这样，你就能一次又一次地使用该方案而不必做重复劳动”。设计模式的焦点在于提供了相干问题的解决方案，使得人们可以更加简朴方便地复用成功的设计和体系结构。
设计模式一般有以下4个基本要素。
(1)模式名称(Pattemm Name)。一个助记名，它用一两个词来描述模式的问题、解决方案和效果。定名一个新的模式增长了设计词汇。设计模式答应在较高的抽象条理上进行设计。基于一个模式词汇表，就可以讨论模式并在编写文档时使用它们。模式名可以资助人们思索,便于人们与其他人互换设计头脑及设计结果。找到适当的模式名也是设计模式工作的难点之一。
(2)问题(Problem)。问题描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，大概描述了特定的设计问题，如怎样用对象表示算法等;也大概描述了导致不机动设计的类或对象结构。偶然候，问题部门会包括使用模式必须满意的一系列先决条件。(3)解决方案(Solution)。解决方案描述了设计的构成因素、它们之间的相互关系及各自的职责和协作方式。由于模式就像一个模板，可应用于多种不同场合。所以解决方案并不描述一个特定的详细的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合(类或对象组合)来解决这个问题。
(4)效果(Consequences)。效果描述了模式应用的效果及使用模式应衡量的问题。尽管描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及利益具有紧张意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。由于复用是面向对象设计的要素之一，所以模式效果包括它对系统的机动性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有资助。
设计模式确定了所包罗的类和实例，它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点，描述了什么时候使用它，在另一些设计约束条件下是否还能使用，以及使用的效果和如何弃取。
按照设计模式的目的可以分为三大类,如表 7-1 所示。
创建型模式与对象的创建有关;结构型模式处置惩罚类或对象的组合;行为型模式对类或对象怎样交互和怎样分配职责进行描述。
7.3.2 创建型设计模式
7.3.3 结构性设计模式
结构型设计模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继续机制来组合接口或实现。一个简朴的例子是采用多重继续方法将两个以上的类组合成一个类，结果这个类包罗了全部父类的性质。这一模式尤其有助于多个独立开发的类库协同工作。此中一个例子是类形式的 Adapter 模式。一般来说，适配器使得一个接口与其他接口兼容，从而给出了多个不同接口的统一抽象。为此，类适配器对一个 adaptee 类进行私有继续。这样，适配器就可
以用 adaptee 的接口表示它的接口。
结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。由于可以在运行时候改变对象组合关系，所以对象组合方式具有更大的机动性，而这种机制用静态类组合是不大概实现的。
Composite 模式是结构型对象模式的一个实例。它描述了如何构造一个类条理式结构，这一结构由两种范例的对象所对应的类构成。此中的组合对象使得用户可以组合基元对象以及其他的组合对象，从而形成恣意复杂的结构。在Proxy 模式中，proxy 对象作为其他对象的一个方便的替代或占位符。它的使用可以有多种形式，例如可以在局部空间中代表一个远程地点空间中的对象，也可以表示一个要求被加载的较大的对象，还可以用来保护对敏感对象的访问。Proxy 模式还提供了对对象的一些特有性质的一定水平上的间接访问，从而可以限定、加强或修改这些性质。Flyweight模式为了共享对象定义了一个结构。至少有两个原因要求对象共享:服从和一致性。Flyweight 的对象共享机制主要夸大对象的空间服从。使用许多对象的应用必须考虑每一个对象的开销。使用对象共享而不是进行对象复制，可以节省大量的空间资源。但是,仅当这些对象没有定义与上下文相干的状态时，它们才可以被共享。Flweight的对象没有这样的状态。任何实行任务时必要的其他一些信息仅当必要时才通报已往。由于不存在与上下文相干的状态，因此 Flyweight 对象可以被自由地共享。
如果说 Flyweight 模式说明了如何生成许多较小的对象，那么 Facade 模式则描述了如何用单个对象表示整个子系统。模式中的facade 用来表示一组对象，facade 的职责是将消息转发给它所表示的对象。Bridge 模式将对象的抽象和其实现分离，从而可以独立地改变它们。Decorator 模式描述了如何动态地为对象添加职责。Decorator 模式是一种结构型模式，这一模式采用递归方式组合对象，从而答应添加恣意多的对象职责。例如，一个包罗用户界面组件的 Decorator 对象可以将边框或阴影这样的装饰添加到该组件中，或者它可以将窗口滚动和缩放这样的功能添加到组件中。可以将一个
Decorator 对象嵌套在另外一个对象中，就可以很简朴地增长两个装饰，添加其他的装饰也是云云。因此，每个Decorator 对象必须与其组件的接口兼容并且包管将消息通报给它。Decorator 模式在转发一条信息之前或之后都可以完成它的工作(例如绘制组件的边框)。许多结构型模式在某种水平上具有相干性。
1. Adapter (适配器)
Adapter (适配器) 意图、结构、适用性 以及应用举例
2. Bridge(桥接)
Bridge (桥接) 意图、结构、适用性 以及应用举例
3.Composite(组合)
1)意图
将对象组合成树型结构以表示“部门-整体”的条理结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。
2)结构
组合模式的结构如图 7-33 所示。
此中:
- Component 为组合中的对象声明接口;在得当情况下实现全部类共有接口的默认行为;声明一个接口用于访问和管理 Component 的子组件;(可选)在递归结构中定义一个接口，用于访问一个父组件，并在符合的情况下实现它。
- Leaf在组合中表示叶结点对象，叶结点没有子结点:在组合中定义图元对象的行为。
- Composite 定义有子组件的那些组件的行为;存储子组件;在Component 接口中实现与子组件有关的操纵。
- Client 通过 Component 接口操纵组合组件的对象。
3)适用性
Composite 模式适用于:
- 想表示对象的部门-整体条理结构。
- 盼望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的全部对象。
4.Decorator(装饰)
1)意图
动态地给一个对象添加一些额外的职责。就增长功能而言,Decorator 模式比生成子类更加机动。
2)结构
装饰模式的结构如图 7-34 所示。
此中:
- Component 定义一个对象接口，可以给这些对象动态地添加职责。
- ConcreteComponent 定义一个对象，可以给这个对象添加一些职责。Decorator 维持一个指向 Component 对象的指针，并定义一个与 Component 接口一致的接口。
- ConcreteDecorator 向组件添加职责。
3)适用性
Decorator 模式适用于:
- 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
- 处置惩罚那些可以撤销的职责。
- 当不能采用生成子类的方式进行扩充时。一种情况是，大概有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数量呈爆炸性增长。另一种情况大概是,由于类定义被隐蔽，或类定义不能用于生成子类。
5.Facade(外观)
1)意图
为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
2)结构
外观模式的结构如图 7-35 所示。
此中:
- Facade 知道哪些子系统类负责处置惩罚哀求;将客户的哀求代理给得当的子系统对象。
- Subsystem classes 实现子系统的功能;处置惩罚有 Facade 对象指派的任务;没有 Facade 的任何相干信息，即没有指向 Facade 的指针。
3)适用性
Facade 模式适用于:
- 要为一个复杂子系统提供一个简朴接口时，子系统往往由于不停演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类，这使得子系统更具有可重用性，也更容易对子系统进行定制,但也给那些不必要定制子系统的用户带来一些使用上的困难。Facade 可以提供一个简朴的默认视图，这一视图对大多数用户来说已经充足，而那些必要更多的可定制性的用户可以越过 Facade 层。
- 客户步伐与抽象类的实现部门之间存在着很大的依赖性。引入Facade 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
- 当必要构建一个条理结构的子系统时，使用 Facade 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，则可以让它们仅通过 Facade 进行通讯，从而简化了它们之间的依赖关系。
6.Flyweight(享元)
1)意图
运用共享技术有效地支持大量细粒度的对象。
2)结构
享元模式的结构如图 7-36 所示。
此中:
- Flyweight 描述一个接口，通过这个接口 Flyweight 可以担当并作用于外部状态
- ConcreteFlyweight 实现 Flyweight 接口，并为内部状态(如果有)增长存储空间。ConcreteFlywweight 对象必须是可共享的。它所存储的状态必须是内部的，即它必须独立于 ConcreteFlyweight 对象的场景。
- 并非全部的 Flyweight 子类都必要被共享。Flywweight 接口使共享成为大概，但它并不强制共享。在 Flyweight 对象结构的某些条理，UnsharedConcreteFlyweight 对象通常将ConcreteFlyweight 对象作为子结点。
- FlyweightFactory 创建并管理 Flyweight 对象;确保合理地共享 Flyweight，当用户哀求一个 Flyweight 时，FlyweightFactony 对象提供一个已创建的实例或者在不存在时创建一个实例。
- Client 维持一个对 Flyweight 的引用;计算或存储一个或多个 Flyweight 的外部状态。
3)适用性
Flyweight 模式适用于:
- 一个应用步伐使用了大量的对象。
- 完全由于使用大量的对象，造成很大的存储开销。
- 对象的大多数状态都可变为外部状态。
- 如果删除对象的外部状态，那么可以用相对较少的共享对象代替许多组对象。
- 应用步伐不依赖于对象标识。由于 Flyweight 对象可以被共享，所以对于概念上明显有别的对象，标识测试将返回真值。
7.Proxy(代理)
1)意图
为其他对象提供一种代理以控制对这个对象的访问
2)结构
代理模式的结构如图 7-37 所示。
此中：
- Proxy 生存一个引用使得代理可以访问实体;提供一个与 Subiect 的接口雷同的接口，使代理可以用来代替实体;控制对实体的存取，并大概负责创建和删除它;其他功能依赖于代理的范例:Remote Proxy 负责对哀求及其参数进行编码，并向不同地点空间中的实体发送已编码的哀求;Vitial Proxy 可以缓存实体的附加信息，以便耽误对它的访问
 rotection Proxy 检查调用者是否具有实现一个哀求所必须的访问权限。
- Subject 定义 RealSubject 和 Proxy 的共用接口，这样就在任何使用 RealSubiect 的地方都可以使用 Proxy。
- RealSubject 定义 Proxy 所代表的实体。
3)适用性
- Proxy 模式适用于在必要比较通用和复杂的对象指针代替简朴的指针的时候,常见情况有:远程代理(Remote Proxy)为一个对象在不同地点空间提供局部代表。
- 虚代理(Vital Proxy)根据必要创建开销很大的对象。
- 保护代理(Protection Proxy)控制对原始对象的访问，用于对象应该有不同的访问权限的时候。
- 智能引用(Smart Reference)代替了简朴的指针，它在访问对象时实行一些附加操纵。典型用途包括:对指向现实对象的引用计数，这样当该对象没有引用时，可以被自动释放;当第一次引用一个持久对象时，将它装入内存;在访问一个现实对象前，检查是否已经锁定了它，以确保其他对象不能改变它。
8. 结构型模式比较
Adapter 模式和 Bridge 模式具有一些功能特性，都给另一个对象提供了一定水平上的间接性,因而有利于系统的机动性,另外都涉及从自身以外的一个接口向这个对象转发哀求。Adapte1模式主要是为解决两个已有接口之间不匹配的问题，不考虑这些接口是怎样实现的，也不考虑它们各自大概会如何演化。这种方式不必要对两个独立设计的类中的任何一个进行重新设计，就能够使它们协同工作。Bridge 模式则对抽象接口与它的(大概是多个)实现部门进行桥接。固然这一模式运行使用者修改实现它的类，但是它仍旧为用户提供了一个稳定的接口，也会在系统演化时适应新的实现。Adapter 模式和 Bridge 模式通常被用于软件生命周期的不同阶段,针对不同的问题。Adapter 模式在类已经设计好后实施;而 Bridge模式在设计类之前实施。
Composite 模式和 Decorator 模式具有类似的结构，说明它们都是基于递归组合来构造可变数量的对象。Decorator 旨在能够不必要生成子类即可给对象添加职责，这制止了静态实现全部功能组合而导致子类急剧增长。Composite旨在构造类,使多个相干的对象能够以统一的方式处置惩罚，而多重对象可以被看成一个对象来处置惩罚，重点在于表示。两者通常协同使用。
Decorator 模式和 Proxy 模式都描述了怎样为对象提供一定水平上的间接引用。Proxy 模式
构成一个对象并为用户提供一致的接口，与 Decorator 模式不同的是，Proxy 模式不能动态地添加或分离性质，也不是为递归组合而设计的，它夸大一种关系(Proxy 与它的实体之间的关系),这种关系可以静态地表达。其目的是，当直接访问一个实体不方便或不符合必要时，为这个实体提供一个替代者，例如，实体在远程设备上，访问受到限定或者实体是持久存储的。在 Proxy模式中，实体定义了关键功能，而 Proxy提供(或拒绝)对它的访问。在Decorator 模式中，组件仅提供了部门功能，而一个或多个 Decorator 负责完成其他功能。Decorator 模式适用于编译时不能(至少不方便)确定对象的全部功能的情况。
7.3.4 行为型设计模式
行为模式涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通讯模式。这些模式刻画了在运行时难以跟踪的、复杂的控制流。它们将用户的注意力
从控制流转移到对象间的联系方式上来。
行为类模式使用继续机制在类间分派行为。本末节包括两个这样的模式。此中Template Method 较为简朴和常用。模板方法是一个算法的抽象定义，它渐渐地定义该算法，每一步调用一个抽象操纵或一个原语操纵，子类定义抽象操纵以详细实现该算法。另一种行为类模式是Imtenpreter，它将一个文法表示为一个类条理，并实现一个解释器作为这些类的实例上的一个操纵。
行为对象模式使用对象复合而不是继续。一些行为对象模式描述了一组对等的对象怎样相互协作以完成此中任一个对象都无法单独完成的任务。这里一个紧张的问题是对等的对象。
如何相互了解对方。对等对象可以保持显式的对对方的引用，但那会增长它们的合度。在极端情况下,每一个对象都要了解全部其他的对象。Mediator 在对等对象间引入一个 mediator
对象以制止这种情况的出现。mediator 提供了松耦合所需的间接性。
Chain ofResponsibility 提供更松的耦合。它让用户通过一条候选对象链隐式地向一个对象发送哀求。根据运行时候情况任一候选者都可以相应相应的哀求。候选者的数量是恣意的，可以在运行时候决定哪些候选者到场到链中。
Observer 模式定义并保持对象间的依赖关系。典型的 Observer 的例子是 Smalltalk 中的模子/视图/控制器，此中，一旦模子的状态发生变革，型的全部视图都会得到关照。
其他的行为对象模式常将行为封装在一个对象中并将哀求指派给它。Stategy 模式将算法封装在对象中，这样可以方便地指定和改变一个对象所使用的算法。Command 模式将哀求封装在对象中，这样它就可作为参数来通报，也可以被存储在汗青列表中，或者以其他方式使用。State 模式封装一个对象的状态，使得这个对象的状态对象变革时，该对象可改变它的行为。Visitor 封装分布于多个类之间的行为，而 Iterator 抽象了访问和遍历一个集合中的对象的方式。
1 Chain of Responsibility 责任链模式
Chain of Responsibility (责任链模式) 意图、结构、适用性 以及应用举例
2 Command （下令模式）
Command （下令模式） 意图、结构、适用性 以及应用举例
3 Interpreter （解释器模式）
Interpreter （解释器模式） 意图、结构、适用性 以及应用举例
4 Iterator （迭代器模式）
Iterator （迭代器模式） 意图、结构、适用性 以及应用举例
5 Mediator （中介者模式）
Mediator （中介者模式） 意图、结构、适用性 以及应用举例
6 Memento （备忘录模式）
Memento （备忘录模式）意图、结构、适用性 以及应用举例
7 Observer （观察者模式）
Observer （观察者模式）意图、结构、适用性 以及应用举例
8 State （状态）
State （状态）意图、结构、适用性 以及应用举例
9 Strategy （战略）
Strategy （战略）意图、结构、适用性 以及应用举例
10 Template Method（模板方法）
Template Method （模板方法）意图、结构、适用性 以及应用举例
11 Visitor （访问者模式）
Visitor（访问者模式）意图、结构、适用性 以及应用举例
12 行为模式比较
许多行为模式注重封装变革。当一个步伐的某个方面的特性经常发生改变时，这些模式就定义一个封装这个方面的对象。这样，当该步伐的其他部门依赖于这个方面时，它们都可以与此对象协作。这些模式通常定义一个抽象类来描述这些封装变革的对象，并且通常该模式依据这个对象来定名。例如:
- 一个 Strategy 对象封装一个算法。
- 一个 State 对象封装一个与状态相干的行为。
- 一个 Mediator 对象封装对象间的协议。
- 一个 Iterator 对象封装访问和遍历一个聚集对象中的各个组件的方法。
这些模式描述了步伐中很大概会改变的方面。大多数模式有两种对象:封装该方面特性的新对象和使用这些新对象的已有对象。但并非全部的对象行为模式都有这样的分割功能，例如。Chain ofResponsibility 可以处置惩罚恣意数量的对象(即一个链)，而全部这些对象大概已经存在于系统中了。这也说明了行为模式的另一个不同点:并非全部的行为式都定义类之间的静态通讯关系。
一些模式引入总是被用作参数的对象。例如 Visitor,一个 Visitor 对象是一个多态的 Accep操纵的参数，这个操纵作用于该 Visitor 对象访问的对象。其他模式定义一些可作为令牌进行通报的对象，这些对象将在稍后被调用。例如，Command和Memento。在 Command 中，令牌代表一个哀求;在 Memento 中，两台代表在一个对象在某个特定时候的内部状态。在这两种情况下，令牌都可以有一个复杂的内部表示，但客户并不会心识到这一点。另外，在Command 模式中多态特别紧张，这是由于实行 Command 对象是一个多态操纵。而 Memento接口非常小，以至于备忘录只能作为一个值通报，因此，它很大概根本不给它的客户提供任何多态操纵。
Mediator 和 Observer 是相互竞争的模式，它们之间的差别是:Observer 通过引入 Observer和 Subject 对象米分布通讯，而 Mediator 对象则封装了其他对象间的通讯。Observer 模式中不存在封装一个约束的单个对象，而必须是 Observer 和 Subiect 对象相互协作来维护这个约束。通讯模式由 Observer 和 Subject 连接的方式决定:一个 Subject通常有多个 Observer，并且偶然一个 Subject 的 Observer 也是另一个 Observer 的日标。Observer 模式有利于 Observer 和 Subiect之间的分割和松耦合，易于产生更细粒度且更易于复用的类。Mediator 模式的目的是集中而不是分布，它将维护一个约束的职责直接放在一个中间者中。
Command、Observer、Mediator 和 Chain ofResponsibility 等模式都涉及如何对发送者和吸收者解耦，但各自有不同的衡量考虑。
Command 模式使用一个 Comand 对象来定义一个发送者和一个吸收者之间的绑定关系,从而支持解耦。Command 对象提供了一个提交哀求的简朴接口(即 Execute 操纵)，将发送者和吸收者之间的连接定义在一个对象，使得该发送者可以与不同的吸收者一起工作，到达将发送者和吸收者解耦，使发送者更易于复用。此外，可以复用Command 对象，用不同的发送者参数化一个吸收者。
Observer 模式通过定义一个接口来关照目标中发生的改变，从而将发送者(目标)与吸收者(观察者)解耦。Observer 定义了一个比 Command 更松的发送者-吸收者绑定，这是由于一个目标大概有多个观察者，并且其数量可以在运行时变革。此模式中的Subiect 和 Observer 接口是为了处置惩罚 Subject 的变革而设计的，因此，当对象间有数据依赖时，最好用此模式来对它
们进行解耦。
Mediator 模式让对象通过一个 Mediator 对象间接相互引用，从而对它们进行解耦。一个Mediator 对象为各 Colleague 对象间的哀求提供路由，并集中它们的通讯。因此，各 Colleague对象仅能通过 Mediator 接口相互通讯。Mediator 接口是固定的，为了增长机动性，Mediator 大概不得不实现它本身的分发战略。可以用一定方式对哀求编码并打包参数，使得Colleague 对象可以哀求的操纵数量不限。由于此模式将通讯行为集中到一个类中而不是将其分布在各个子类中，所以它可以减少一个系统的子类生成。
Chain of Responsibility 模式通过沿一个潜在吸收者链通报哀求而将发送者与吸收者解耦。
由于发送者和吸收者之间的接口是固定的，责任链大概也必要一个定制的分发战略。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
