软考中级-设计模式

1 创建型设计模式

抽象了实例化过程，类创建型模式使用继承改变被实例化的类，对象创建型模式将实例化委托给另一个对象。创建型模式将系统具体使用哪些类信息封装起来，隐藏了这些类是如何被创建和组合的，只知道抽象类所定义的接口。

1.1 简单工厂模式

不属于23种设计模式，它定义了一个工厂，根据参数的不同返回不同类的实例，这些实例通常拥有共同的父类。

用于创建实例的方法通常为static方法，故简单工厂模式又称为静态工厂方法。

三类角色：

工厂：负责实现创建所有产品的方法，可直接被外部调用。

抽象产品：所有产品的父类，声明了公共方法

具体产品：被创建实例的类，实现了抽象产品中的方法。

缺点：不遵循开闭原则

1.2 工厂方法模式（创建型类模式，其余创建型模式均为创建型对象模式）

意图：定义一个用于创建对象的接口，将具体实例化哪个实例延迟到其子类来决定。

结构：四类角色

抽象产品：声明产品的接口。

具体产品：实现产品的接口。

抽象工厂：声明工厂创建产品的接口。

具体工厂：实现产品创建接口，返回具体的产品实例。

适用性：

• 当一个类不知道他所必须创建的对象的类的类型的时候。

• 当一个类希望由他的子类决定创建的实例的类型的时候。

• 当类将创建对象的职责委托给多个帮助子类种的某个时，并且你希望其中哪个子类是代理者的时候。

1.3 抽象工厂模式

意图：提供一个创建一系列相关或相互依赖的对象的接口，而无需指定他们的类。

结构：

抽象产品：声明产品的接口，其中包含了该产品的一条产品线。

具体产品：产品线中具体的各产品类，实现产品的接口。

抽象工厂：声明工厂创建产品的接口。

具体工厂：实现一类产品的创建接口，返回具体的产品实例。

适用性：

• 一个系统要由多个产品系列中的一个来配置时。

• 当一个系统应该独立于他的产品的创建、构成和表示时。

与工厂方法模式的区分：一个具体工厂可创建多个产品则为抽象工厂。

1.4 生成器模式

意图：将一个复杂对象的构建与其表示分离，使得一种构建可以产生多种不同的表示。

结构:

Builder：声明构建产品的抽象接口。

ConcreteBuilder：实现产品的构建（创建该产品的内部表示，包括该产品由那些类组成）和装配（由哪些接口来将前述这些类组装成产品）的接口，并实现获取产品的接口。

Director：创建使用builder接口的对象。

适用性：

• 当创建复杂产品的算法应该独立与该对象的组成部分及装配部分时。

• 当构造过程必须允许构造对象有多个不同的表示时。

1.5 原型模式

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

结构：

Prototype：抽象原型，提供克隆接口。

concretePrototype：具体原型，实现具体的克隆方法。

client：调用原型的克隆。

适用性：

• 一个系统要独立于它产品的创建、构成和表示时。

• 当实例化的类是在运行时指定，如动态装载。

• 为了避免创建一个与产品类层次平行的工厂类时。

• 当一个类的实例只能有几个不同状态组合中的一种时，建立一个原型并在需要时克隆，可能比每次手动创建实例方便些。

1.6 单例模式

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

结构：

适用性：

• 当类只有一个实例并且客户可以从一个众所周知的访问点访问它时。

• 当这个唯一实例是通过子类化可拓展的，并且客户无需更改代码就能拓展时。

2 结构型设计模式

2.1 适配器模式（类、对象模式，其余结构性模式均为对象模式）

意图：将一个类的接口转化为客户希望的另一种接口，使原本不兼容的可一起工作。

结构：

Target：用户要使用的目标接口

Adaptee：已存在的接口，但此时并不适配。

Adapter：将Adaptee接口与Target接口进行适配

Client：用户

适用性：

• 想使用一个已存在的类，但其接口不适用。

• 想创建一个可复用的类，该类可以与不相关或不可预见的类相适配。

2.2 桥接模式

意图：将抽象部分和实现部分分离，使他们都可独自变化。

结构：

Abstraction：抽象类接口，维护了一个指向实现类的指针。

RefineAbstraction：抽象类的子类。

Implementor：实现类的接口，可以与Abstraction提供的接口完全不同，Implementor提供基本的接口，Abstraction提供基于基本接口的较高层次的接口。

ConcreteImplementor：实现接口。

适用性：

• 不希望抽象和实现部分有固定的绑定关系。

• 类的抽象和实现都可以通过子类扩充。

• 想对客户隐藏实现部分。

• 有许多类要生成的类层次结构。

• 想在多个对象间共享实现。

2.3 组合模式

意图：将对象组合成树形结构以表示”部分-整体“的层次结构，使得用户对单个和组合对象使用一致。

结构：

Component：为组合中的对象声明接口，访问和管理其子组件。

Leaf：叶子节点对象，没有子节点，定义图元对象的行为。

Composite：定义有子组件的那些组件的形为，存储子组件，存储子组件。

适用性：

• 表示对象的部分-整体层次结构。

• 希望用户忽略组合对象和单个对象的不同，从而统一的使用所有对象。

2.4 装饰器模式

意图：动态的给一些对象添加一些额外职责，比生成子类更加灵活。

结构：

Component：定义一个对象接口，可以给这些对象动态添加职责。

ConcreteComponent：定义一个具体对象，可以给他添加职责。

Decorate：维持一个指向Component对象的指针，并定义一个与Component一样的接口。

ConcreteDecorate：向组件添加职责。

适用性：

• 在不影响其他对象的前提下，以动态、透明的方式添加职责。

• 处理那些可以撤销的职责。

• 当不能采用生成子类的方式进行扩充时。

2.5 外观模式

意图：为子系统中一组接口提供一个一致的界面，定义了一个高层接口，这个接口使得这子系统更加容易被使用。

结构：

Facade：知道哪些子系统负责处理请求，将请求代理给适当的子系统。

subSystem：实现子系统的功能，处理Facade指派的任务，没有任何Facade的信息（子系统不会感受到外观的存在）。

适用性：

• 要为一个复杂子系统提供一个简单接口。

• 客户程序与抽象类之间存在很强的依赖性。

• 当需要构建一个层次结构的子系统，使用外观模式提供每层的入口。

2.6 享元模式

意图：利用共享技术有效的支持大量细粒度对象。

结构：

FlyWeight：提供接口，接受并作用外部状态。

ConcreteFlyWeight：实现接口，里面的内容是内部状态，可共享的。

UnSharedConcreteFlyWeight：实现接口，里面内容是外部的，不共享的。

FlyWeightFactory：创建并管理FlyWeight。

适用性：

• 一个应用程序使用了大量对象。

• 完全由于使用大量对象，造成很大的存储开销。

• 对象的大多数状态都可变为外部状态。

• 如果删除对象的外部状态，那么可以用相对较少的享元对象取代很多组对象。

2.7 代理模式

意图：为其他对象提供一种代理以控制并访问其他对象。

结构：

Proxy：保存一个引用，使得代理可以访问实体，提供与实体相同的接口，使得代理可以代替实体（控制实体存取、创建和删除实体）。

Subject：定义RealSubject和Proxy的接口，使得可以在任何使用RealSubject的地方使用Proxy。

RealSubject：定义具体的需被代理的对象。

适用性：

• 需要一个通用且复杂的对象代替简单的对象做事时。

3 行为型设计模式

3.1 解释器模式（行为型类模式）

意图：定义一个语言，定义它文法的一种表示，并定义一个解释器，这个解释器使用这种表示来解释语言。

结构：

AbstractExpression：声明一个程序的解释操作，这个操作被抽象语法树中所有节点所共享。

TerminalExpression：实现文法中与终结符相关的解释操作，每个终结符都需要一个该实例。

NonterminalExpression：非终结符解释器，每个规则都需要一个NonterminalExpression类，每个符号都维护一个NonterminalExpression实例

适用性：

• 该文法简单。

• 效率不是关键问题。

3.2 模板方法模式（行为型类模式）

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

结构：

AbstractClass：定义抽象的原始操作，具体的子类将重定义他们以实现一个算法的各步骤；实现模板方法，定义一个算法的骨架；该模板方法不仅调用原语操作，也调用定义在AbstractClass或其他对象中的操作。

ConcreteClass：实现原语操作以完成算法中与某些特定子类相关的步骤。

适用性：

• 父类一次性实现算法中不变的部分，将变化的部分留给子类去实现。

• 各子类中公共的行为应该被提取出来留给父类去实现。

• 控制子类只能在这些可变的部分中进行拓展。

3.3 责任链模式

意图：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间出现耦合，将这些对象连成一条链，挨个传递请求，直到有一个对象处理请求为止。

结构：

Handler：定义一个处理请求的接口。

ConcreteHandler：负责他所处理的请求，可访问它的后继者，如果它处理不了，就传递给后继者。

适用性：

• 有多个对象可以处理该请求，具体谁处理在运行时刻决定。

• 在不明确具体接收者时想想多个对象中的一个发送请求。

• 可处理一个请求的对象集合希望被动态指定。

3.4 命令模式

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

结构：

Command：声明执行操作的接口。

ConcreteCommand：将一个接收者对象绑定一个动作，调用接收者相应的操作，以实现执行。

Client：创建一个具体命令对象并设置他的接收者。

Invoker：要求该命令执行该请求。

Receiver：知道如何实施与执行一个请求相关的操作，任何类都可以是一个Revicer。

适用性：

• 抽象出待执行的动作以参数化某对象。

• 在不同的时刻指定、排列和执行请求。

• 支持取消操作。

• 支持修改日志。

• 用构建在原语操作上高级操作构建一个系统。

3.5 迭代器模式

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

结构：

Iterator：定义访问和遍历的接口。

ConcreteIterator：实现迭代器接口，对该聚合访问时跟踪当前位置。

Aggregate：定义创建相应迭代器对象的接口。

ConcreteAggregate：实现创建相应迭代器的接口，该操作返回ConcreteAggregate的一个适当实例。

适用性：

• 访问一个聚合对象的内容而无需暴露他的内部表示

• 支持对聚合对象的多种遍历。

• 为遍历不同的聚合结构提供一个统一的接口。

3.6 中介者模式

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

结构：

Mediator：定义一个交互用于各同事（Colleague）之间的交互。

ConcreteMediator：通过协调各同事对象实现协作形为，了解并维护他的各个交互。

Colleague：了解它的中介对象，在需要与其他同事通信时与中介对象通信。

适用性：

• 一组对象以定义良好但是复杂的方式进行通信，产生关系结构混乱难以维护。

• 一个对象引用其他很多对象并直接与这些对象进行通信，导致难以复用。

• 想定义一个分布在多个类中行为，但又不想定义太多子类。

3.7 备忘录模式

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

结构：

Mementor（备忘录）：储存原发器对象的内部状态，原发器根据需要决定备忘录存储原发器的哪些内部状态；防止原发器以外的对象访问备忘录。

Originator（原发器）：创建一个备忘录，用于记录当前时刻他的内部状态；使用备忘录恢复内部状态。

Caretaker（管理者）：负责保存好备忘录，不能对备忘录的内容进行操作或检查。

适用性：

• 需要保存一个对象在某一时刻的状态，这样可以在未来需要时恢复到该状态。

• 如果一个用接口来让其他对象直接得到这些状态，将会暴露对象的实现细节并且破坏封装性。

3.8 观察者模式

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

结构：

Subject（目标）：知道他的观察者，可以有多个观察者观察一个目标，提供注册和删除观察者的接口。

Observer：为那些目标发生改变时需要更新的对象定义一个更新接口。

ConcreteSubject：将有关状态存入各ConcreteObserver对象，当他的状态发生改变时，向他的各观察者发送通知。

ConcreteObserver：维护一个指向ConcreteSubject对象的引用，存储有关状态，这些状态应与目标的状态保持一致；实现Observer的更新接口，使状态与目标保持一致。

适用性：

• 当一个抽象模型有两个方面，其中一个方面依赖另一方面，将这两者封装在独立的对象中以使他们可以独立的改变和复用。

• 当一个对象的改变需要同时通知其他对象，而不知道具体有多少对象需要改变时。

• 当一个对象必须通知其他对象，而他又不能假定对象是谁，即不希望这些对象是紧耦合的。

3.9 状态模式

意图：允许一个对象在其内部状态改变时改变他的行为，使对象看起来似乎修改了他的类。

结构：

Context（上下文）：定义客户端感兴趣的接口，维护一个ConcreteState的实例，这个实例定义当前状态。

State：定义一个接口以封装与Context的一个特征状态相关的行为。

ConcreteState：每个ConcreteState子类实现一个与Context一个状态相关的行为。

适用性：

• 一个对象的行为取决于他的状态，并且他必须在运行时刻决定他的状态。

• 一个操作中含有庞大的多分枝条件语句，这些分支依赖于该对象的状态，这些状态一般为枚举。

3.10 策略模式

意图：定义一系列的算法，把它们一一封装起来，并是他们可以相互替换，使得算法可以独立于使用它的客户而变化。

结构：

Context（上下文）：用一个ConcreteStrategy对象来配置，维护一个Strategy对象的引用，定义一个接口让strategy对象访问上下文的数据。

Strategy：定义一个支持所有算法的公共接口，context通过这个接口调用ConcreteStrategy算法。

ConcreteStrategy：实现某一具体算法。

适用性：

• 许多相关的类仅仅是行为有异。

• 需要使用一个算法的不同变体。

• 算法使用客户不应该知道的数据。

• 一个类定义了许多行为，并且这些行为在这个类的操作中以条件语句进行使用。

3.11 访问者模式

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

结构：

Visitor：为该对象结构中每一个ConcreteVisitor对象都定义一个visit操作，该操作的名字和特征标识了发送visitor请求给该访问者的哪个类，这使得访问者可以确定正被访问元素的具体的类，这样访问者就可以通过该元素的特定接口直接访问它。

ConcreteVisitor：实现每一个Visitor声明的操作，每个操作实现本算法的一部分，而该算法片段是对应对象结构中对象的类

Element：定义以访问者为参数的Accept操作。

ConCreteElement：实现以访问者为参数的Accept操作。

ObjectStruct（对象结构）：能枚举他的元素；可以提供一个高层接口以允许访问者访问它的元素；可以是一个组合或集合，如列表或无序集合。

适用性：

• 一个对象结构包含很多类对象，他们有不同的接口，而用户想对这些对象实施一些依赖于具体类的操作。

• 需要对一个对象结构中的许多类进行不同且不相关的操作。

4 总结

汇总：23 = 5（创建型，其中） + 7（结构型） +11（行为型）

创建型：类模式（1），对象模式（4）

结构型：类模式（1），对象模式（7）

行为型：类模式（2），对象模式（9）