每一天从不跳舞，这是对生活的失望.(2)

参考文献:

将请求封装为对象，以便您可以将具有不同请求的客户参数化；排队或记录请求，并支持不可撤消的操作.

ConcreteCommandClientInvokerReceiverCommand模式将调用操作的对象与知道如何实现该操作的对象分离. 命令是一流的对象. 它们可以像其他对象一样被操纵和扩展. 您可以将多个命令组合成一个复合命令. 添加新命令很容易，因为它不需要更改现有的类.

参考文献:

给出一种语言，定义其语法表示形式，并定义一个解释器，使用该表示形式来解释该语言中的句子.

TerminalExpressionNonterminalExpressionContextClient易于更改和扩展语法. 实施语法也很容易. 复杂的语法难以维护. 添加了解释表达式的新方法，并且解释器模式使实现新表达式“计算”变得容易.

参考文献:

提供一种在不暴露对象内部表示的情况下顺序访问聚合对象中每个元素的方法.

ConcreteIteratorAggregateConcreteAggregate它支持以不同方式遍历聚合. 复杂的聚合可以以多种方式遍历. 迭代器简化了聚合接口. 使用迭代器遍历接口，聚合本身不再需要类似的遍历接口. 同一聚合上可以有多个遍历，并且每个迭代器都保持自己的遍历状态.

参考文献:

封装一系列与中间对象的对象交互. 中介消除了对象之间显式引用的需要，从而消除了它们之间的耦合，并且可以独立地更改其交互.

ConcreteMediatorColleague类减少了子类的生成. 中介器集中了最初在多个对象之间分发的行为. 它使每个同事解耦，而调解员则促进了同事之间的松散耦合. 它简化了对象协议，并用Mediator与同事之间的一对多交互代替了多对多交互. 它使用中介作为一个独立的概念并将其封装在一个对象中，抽象了对象如何协同工作，使您可以将注意力从对象本身的行为转移到它们的交互. 它集中了控制网络设计模式，中介模型将交互的复杂性转变为中介的复杂性.

参考文献:

在不影响封装的情况下，捕获对象的内部状态并将此状态保存在对象外部. 将来会将对象恢复到其原始保存状态.

OriginatorCaretaker维护程序包边界. 它简化了启动器. 使用备忘录可能会很昂贵. 定义狭窄和广泛的接口. 维护备忘录的潜在成本.

参考文献:

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

ObserverConcreteSubjectConcreteObserver目标和观察者之间的抽象耦合. 支持广播通讯. 意外的更新.

参考文献:

允许对象在其内部状态更改时更改其行为. 该对象似乎在修改其类.

StateConcreteState子类它本地化与特定状态有关的行为，并分隔不同状态的行为. 它使状态转换变得明确. 状态对象可以共享.

参考文献:

定义一系列算法，将它们一个接一个地封装，并使它们可互换. 此模型允许独立于使用它的客户端来更改算法.

与ConcreteStrategyContext相关的算法系列. 策略类层次结构为上下文定义了一系列可重用的算法或行为. 继承的替代方法，继承提供了支持多种算法或行为的另一种方法. 消除了一些条件语句策略模式为通过条件语句选择所需行为提供了一种选择.

参考文献:

定义操作中算法的框架，并将某些步骤推迟到子类. TemplateMethod允许子类重新定义算法的某些特定步骤，而无需更改算法的结构.

ConcreteClass模板方法是代码重用的基本技术. 模板方法导致了逆控制结构.

参考文献:

表示作用于对象结构中每个元素的操作. 它允许您在不更改每个元素的类的情况下对这些元素定义新的操作.

ConcreteVisitorElementConcreteElementObjectStructure访问者模式使添加新操作变得容易. 访问者可以轻松添加依赖于复杂对象结构的组件. 访客集中相关的操作，并分离无关的操作. 相关行为并不分布在定义对象结构的每个类中，而是集中在一个访问者中. 添加新的ConcreteElement类很困难，Visitor模式使添加新的Element子类变得困难. 通过类层次结构进行访问. 累积状态. 打破包装.

参考文献:

这些模式描述了程序中可能更改的各个方面. 大多数模式都有两种类型的对象: 封装方面特征的新对象，以及使用这些新对象的现有对象. 没有这些模式，这些新对象的功能通常就成为这些现有对象不可分割的一部分. 例如，策略的代码可以嵌入其Context类中，而状态的代码可以直接在该状态的Context类中实现.

但并非所有对象都以这种方式运行. 例如，“责任链”可以处理任意数量的对象（即链），并且所有这些对象可能已存在于系统中. 责任链说明了行为模式之间的另一个区别: 并非所有的行为模式都定义了类之间的静态通信关系. 责任链提供了一种在数量可变的对象之间进行通信的机制. 其他模式涉及作为参数传递的对象.

某些模式会引入始终用作参数的对象. 例如，访客. 一个Visitor对象是一个多态Accept操作的参数，该操作对Visitor对象访问的对象进行操作. 尽管过去替换访问者模式的常用方法是将访问者代码分布在某些类的对象结构中，但访问者从来都不是它访问的对象的一部分.

** Command和Memento定义了可以作为标记传递的对象，这些对象将在以后被调用. 在Command中，令牌代表请求；在Memento中，它表示对象在特定时刻的内部状态. **在两种情况下，令牌都可以具有复杂的内部表示形式，但是客户并不知道. 但是这里有一些区别: 多态在Command模式下很重要，因为执行Command对象是多态操作. 相比之下，Memento界面是如此之小，以至于备忘录只能作为值传递. 因此，它很可能根本不会向其客户提供任何多态操作.

Mediator和Observer是竞争模型. 它们之间的区别在于，观察者通过引入观察者和主题对象来分发通信，而中介者对象则封装了其他对象之间的通信.

在观察者模式中，没有单个对象封装约束. 取而代之的是，Observer和Subject对象必须协作以维护此约束. 通信模式由观察者和目标之间的连接方式决定: 一个目标通常有多个观察者，有时一个目标的观察者也是另一个观察者的目标. 中介者模式的目的是集中而不是分配. 它负责直接在中介机构中维护约束.

我们发现，生成可重用的观察者和主题比生成可重用的调解器更容易. 观察者模式有利于观察者与主体之间的划分和松散耦合. 同时，这将产生更好的粒度，从而更容易重用类.

另一方面，与Observer相比，Mediator中的通信流程更易于理解. 观察者和目标通常在创建后不久就连接在一起，此后很难在程序中看到它们是如何连接的. 如果您了解了观察者模式，您将知道观察者与目标之间的连接是多么重要，并且还知道要寻找哪些连接. 但是，Observer模型引入的间接性仍然使系统难以理解.

当协作对象彼此直接引用时，它们变得相互依赖，这可能对系统的分层和重用产生负面影响. 指挥官，观察员，中介机构和责任链都涉及如何使发送者和接收者脱钩，但是他们每个人都需要权衡取舍.

命令模式使用Command对象定义发送方和接收方之间的绑定关系，从而支持解耦. Command对象提供了用于提交请求（即Execute操作）的简单接口. 在单独的对象中定义发送方和接收方之间的连接，可以使发送方与其他接收方一起工作. 这使发送者与接收者解耦，从而使发送者更易于重用. 此外，您可以重用Command对象以参数化具有不同发送者的接收者. 尽管“命令”模式描述了避免生成子类的实现技术，但名义上每个发送者-接收者连接都需要一个子类.

观察者模式通过定义接口来通知目标更改，从而将发送者（目标）与接收者（观察者）分离. 观察者定义了比Command更宽松的发送者-接收者绑定，因为目标可能有多个观察者，并且其数目可以在运行时更改.

介体模式通过通过介体对象间接引用对象来解耦对象. 中介者对象为同事对象之间的请求提供路由，并集中它们之间的通信. 因此，同事对象只能通过Mediator界面互相交谈. 因为此接口是固定的，所以Mediator可能必须实施自己的分发策略以增加灵活性. 可以对请求进行编码和打包参数，以使同事对象可以请求的操作数不受限制. 介体模式可以减少系统中子类的生成，因为它将通信行为集中在一个类中，而不是将其分配在子类中. 但是，临时分配策略通常会降低类型安全性.

责任链模型通过沿着潜在的接收者链传递请求，将发送者与接收者解耦. 由于发送方和接收方之间的接口是固定的，因此责任链可能还需要定制的分发策略. 因此，它具有与调解器相同的类型安全问题. 如果责任链已经是系统结构的一部分，并且链上的多个对象之一可以同时处理请求，那么责任链将是一种将发送方与接收方分离的好方法. 另外，由于可以轻松地更改和扩展链，因此该模型提供了更大的灵活性.

想更多地了解设计模式: 设计模式专栏

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-162343-2.html