命令模式

意图

将一个请求封装为一个对象，从而使你可以在接收不同的请求、请求队列或者日志请求时对客户进行参数化，并且支持可撤消的操作。

使用场景

当你有如下需求时，可使用Command模式：

• 可以抽象出待执行的动作以参数化某对象。
  
  你可用过程语言中的回调(callback)函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。Command模式是回调机制的一个面向对象的替代品。
• 在不同的时刻指定、排列和执行请求。
• 支持取消操作。
• Command模式提供了对事务进行建模的方法。

结构

命令模式结构如下

• Command
  
  – 声明执行操作的接口。

• ConcreteCommand
  
  – 将一个Receiver对象与一个Action绑定。
  
  – 调用接收者相应的操作，以实现Execute。

• Client
  
  – 创建一个Concrete Command对象并设定它的Receiver。

• Invoker
  
  – 要求该命令执行这个请求。

• Receiver
  
  – 知道如何实施与执行一个请求相关的操作。任何类都可能作为一个Receiver。

协作

1. Client创建一个ConcreteCommand对象并指定它的Receiver对象。
2. 某Invoker对象存储该ConcreteCommand对象。
3. 该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤消的，ConcreteCommand就在执行Excute操作之前存储当前状态以用于取消该命令。
4. ConcreteCommand对象对调用它的Receiver的一些操作以执行该请求。

时序图如下所示

效果

• Command模式将调用操作的对象与知道如何实现该操作的对象解耦。
• Command是顶层的对象。它们可像其他的对象一样被操纵和扩展。
• 你可将多个命令装配成一个复合命令
• 扩展性良好，增加新的Command很容易，因为这无需改变已有的类。

模板方法模式

意图

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

使用场景

模板方法应用于下列情况：

• 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
• 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
• 控制子类扩展。

结构

模板方法结构如下

• AbstractClass
  
  – 定义抽象的基本操作(Primitive Operation)，具体的子类将重写它们来实现一个指定算法的步骤。
  
  – 实现一个模板方法，定义一个算法的骨架。该模板方法不仅调用接口中的基本操作，也调用定义在AbstractClass或其他对象中的操作。

• ConcreteClass
  
  – 实现基本操作来完成算法中与指定子类相关的步骤。

协作

ConcreteClass靠AbstractClass来实现算法中不变的步骤。

效果

模板方法模式是一种代码复用的基本技术。它们在类库中尤为重要，它们提取了类库中的公共行为。

• 模板方法模式使得扩展性更好
• 模板方法指定了逻辑，如果为模板方法添加final修饰符，那么子类也不能去修改逻辑。
• 钩子方法(Hook Method)在抽象中提供一个方法的空实现，子类可以根据自身需要来决定是否进行实现扩展。

状态模式

状态模式(Strategy Pattern)又名状态对象(Objects for States)

意图

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

使用场景

当出现下面的两种情况之一时使用State模式

• 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
• 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

结构

状态模式结构如下

• Context
  
  – 定义Client所关注的接口。
  
  – 维护一个ConcreteState子类的实例，这个实例定义当前状态。

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

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

协作

• Context将与状态相关的请求委托给当前的ConcreteState对象处理。
• Context可将自身作为一个参数传递给处理该请求的状态对象。这使得状态对象在必要时可访问Context。
• Context是客户使用的主要接口。客户可用状态对象来配置一个Context，一旦一个Context配置完毕, 它的Client不再需要直接与状态对象打交道。
• Context或ConcreteState子类都可决定哪个状态是另外哪一个的后继者，以及是在何种条件下进行状态转换。

效果

State模式有下面一些效果

• 它将与特定状态相关的行为局部化，并且将不同状态的行为分割开来
  
  – State模式将所有与一个特定的状态相关的行为都放入一个对象中。因为所有与状态相关的代码都存在于某一个State子类中, 所以通过定义新的子类可以很容易的增加新的状态和转换。
  
  – State模式避免使用大量的ifelse语句或者switchcase语句来控制状态，但是可能会引入更多的类，增加了子类的数目
• 它使得状态转换显式化
  
  – 当一个对象仅以内部数据值来定义当前状态时, 其状态仅表现为对一些变量的赋值，这不够明确。为不同的状态引入独立的对象使得转换变得更加明确。而且, State对象可保证Context不会发生内部状态不一致的情况，因为从Context的角度看，状态转换是原子的–只需重新绑定一个变量(即Context的State对象变量)，而无需为多个变量赋值。
• State对象可被共享
  
  – 如果State对象没有实例变量–即它们表示的状态完全以它们的类型来编码–那么各Context对象可以共享一个State对象。当状态以这种方式被共享时, 它们必然是没有内部状态, 只有行为的轻量级对象(Flyweight Pattern)。

策略模式

策略模式(Strategy Pattern)又名政策模式(Policy Pattern)

意图

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

使用场景

当存在以下情况时使用Strategy模式

• 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
• 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。
• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
• 一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

结构

策略模式结构如下

• Strategy
  
  – 定义所有支持的算法的公共接口。Context使用这个接口来调用某ConcreteStrategy定义的算法。

• ConcreteStrategy
  
  – 以Strategy接口实现某具体算法。

• Context
  
  – 用一个ConcreteStrategy对象来配置。
  
  – 维护一个对Strategy对象的引用。
  
  – 可定义一个接口来让Strategy访问它的数据。

协作

• Strategy和Context相互作用以实现选定的算法。当算法被调用时, Context可以将该算法所需要的所有数据都传递给该Strategy。或者，Context可以将自身作为一个参数传递给Strategy操作。这就让Strategy在需要时可以回调Context。

• Context将它的客户的请求转发给它的Strategy。客户通常创建并传递一个ConcreteStrategy对象给该Context；这样, 客户仅与Context交互。通常有一系列的ConcreteStrategy类可供客户从中选择。

效果

优点

• Strategy类层次为Context定义了一系列的可供重用的算法或行为。将Context与Strategy层次进行了解耦，不需要通过继承Context增加Context子类来完成策略的实现，这样易于扩展。
• 消除了大量条件语句，大量的使用条件语句使得代码看上去十分混乱
• Strategy模式可以提供相同行为的不同实现。

缺点

• Client要想选择一个合适的Strategy，就必须去了解Strategy的具体区别，此时可能会向Client暴露具体的实现
• 增加了Strategy与Context之间的通信开销
• 增加了对象的数量

代理模式

意图

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

使用场景

代理对象目标是控制它所代理的对象的初始化与访问。一个常见的应用场景是，在创建一些实例化开销较大的对象时，代理可以将创建过程推迟到真正需要该对象的时候。

结构

代理模式结构如下

• Proxy
  
  – 保存一个引用使得代理可以访问实体。若RealObject和Subject的接口相同，Proxy会引用Subject。
  
  – 提供一个与Subject的接口相同的接口，这样代理就可以用来替代RealObject。
  
  – 控制对RealSubject的存取，并可能负责创建和删除它。

• Subject
  
  – 定义RealObject和Proxy的共用接口，这样就在任何使用RealObject的地方都可以使用Proxy。

• RealObject
  
  – 定义Proxy所代表的实体。

协作

代理根据其种类，在适当的时候向RealObject转发请求。

优点

• 职责清晰地分离了
• 扩展性良好
• 动态代理可以在运行阶段指定代理的对象

享元模式

意图

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

使用场景

Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。当以下情况都成立时使用Flyweight模式：

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

结构

享元模式结构如下

• Flyweight
  
  – 描述一个接口，通过这个接口flyweight可以接受并作用于外部状态。

• ConcreteFlyweight
  
  – 实现Flyweight接口，并且为内部状态(如果有)提供储存。一个ConcreteFlyweight对象必须是可以共享的。它所存储的任何状态都应该是内部的，也就是说，它必须独立于ConcreteFlyweight对象的上下文(Context)。

• UnsharedConcreteFlyweight
  
  – 并非所有的Flyweight子类都需要被共享。Flyweight接口提供了共享的能力，但是它并不是强制共享。在Flyweight的某些层次，UnsharedConcreteFlyweight对象通常会将ConcreteFlyweight对象当做子节点。

• FlyweightFactory
  
  – 创建并且管理Flyweight对象
  
  – 确保flyweights对象能被合理地共享。当一个client请求一个flyweight时，FlyweightFactory对象提供一个已经存在的实例或者新建一个(如果一个都不存在的话)。

• Client
  
  – 维护一个对flyweight的引用
  
  – 计算或者储存flyweight对象的外部状态

协作

• flyweight执行时所需的状态必定是内部的或外部的。内部状态存储于ConcreteFlyweight对象之中；而外部状态则由Client对象存储或计算。当用户调用flyweight对象的操作时，将该外部状态传递给它。
• Client不应直接对ConcreteFlyweight类进行实例化，而只能从FlyweightFactory对象得到ConcreteFlyweight对象，这可以保证对它们适当地进行共享。

优点

使用Flyweight模式时，传输、查找和/或计算外部状态都会产生运行时的开销，尤其当flyweight原先被存储为内部状态时。然而，空间上的节省抵消了这些开销。共享的flyweight越多，空间节省也就越大。
存储节约由以下几个因素决定：

• 因为共享，实例总数减少的数目
• 对象内部状态的平均数目
• 外部状态是计算的还是存储的

共享的Flyweight越多，存储节约也就越多。节约量随着共享状态的增多而增大。当对象使用大量的内部及外部状态，并且外部状态是计算出来的而非存储的时候，节约量将达到最大。所以，可以用两种方法来节约存储：用共享减少内部状态的消耗，用计算时间换取对外部状态的存储。

外观模式

意图

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

使用场景

以下情况使用Facade模式:

• 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
• 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
• 当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。

结构

外观模式结构如下

• Facade
  
  – 知道哪些子系统类负责处理请求。
  
  – 将客户的请求代理给适当的子系统对象。

• Subsystem
  
  – 实现子系统的功能。
  
  – 处理由Facade对象指派的任务。
  
  – 没有Facade的任何相关信息；即没有指向Facade对象的引用。

协作

客户程序通过发送请求给Facade的方式与子系统通讯，Facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但Facade模式本身也必须将它的接口转换成子系统的接口。使用Facade的客户程序不需要直接访问子系统对象。

装饰模式

装饰模式(Decorator Pattern)也叫做包装器(Wrapper)

意图

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

使用场景

以下情况使用Decorator模式:

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

结构

装饰模式结构如下

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

• ConcreteComponent
  
  – 定义一个对象，可以给这个对象添加一些职责。

• Decorator
  
  –维持一个指向Component对象的引用，并定义一个与Component接口一致的接口。

• ConcreteDecorator
  
  –向Component添加职责。

协作

Decorator将请求转发给它的Component对象，并有可能在转发请求前后执行一些附加的动作。

组合模式

意图

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

使用场景

以下情况使用Composite模式:

• 你想表示对象的部分-整体层次结构。
• 你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

结构

组合模式结构如下

• Component
  
  –为组合中的对象声明接口。
  
  –在适当的情况下，实现所有类共有接口的缺省行为。
  
  –声明一个接口用于访问和管理Component的子组件。
  
  –(可选)在递归结构中定义一个接口，用于访问一个父部件，并在合适的情况下实现它。

• Leaf
  
  – 在组合中表示叶节点对象，叶节点没有子节点。
  
  – 在组合中定义图元对象的行为。

• Composite
  
  –定义有子部件的那些部件的行为。
  
  –存储子部件。
  
  –在Component接口中实现与子部件有关的操作。

• Client
  
  –通过Component接口操纵组合部件的对象。

协作

用户使用Component类接口与组合结构中的对象进行交互。如果接收者是一个叶节点,则直接处理请求。如果接收者是Composite, 它通常将请求发送给它的子部件，在转发请求之前与/或之后可能执行一些辅助操作。

桥接模式的定义

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

使用场景

以下情况使用Bridge模式

• 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。
• 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge模式让你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
• 对一个抽象的实现部分的修改应对客户端不产生影响，即调用者的代码不必重新编译。
• 有大量的类要生成，这种类的继承关系印证了将对象拆分成多个部分的需求
• 你想在多个对象之间共享实现又想对调用者隐藏细节时

结构

桥接模式结构如下

• Abstraction
  
  – 定义抽象类的接口。
  
  – 维护一个指向Implementor类型对象的引用。

• RefinedAbstraction
  
  – 扩充由Abstraction定义的接口。

• Implementor
  
  – 定义实现类的接口，该接口不一定要与Abstraction的接口完全一致；事实上这两个接口可以完全不同。一般来讲，Implementor接口仅提供基本操作，而Abstraction则定义了基于这些基本操作的较高层次的操作。

• ConcreteImplementor
  
  – 实现Implementor接口并定义它的具体实现。

协作

Abstraction将Client的请求转发给它的Implementor对象。