策略模式（Strategy）

定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

优点

  • 以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合
  • Strategy类层次为Context定义了一系列可重用的算法或行为。继承有助于析取出这些算法中的公共功能
  • 简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试
  • 不同的行为堆砌在一个类中时，很难避免使用条件语句来选择合适的行为。将这些行为封装在一个个独立的Strategy类中，可以在使用这些行为的类中消除条件语句

应用

  • 需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性
  • 选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象

模板方法模式（Template Method）

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

优点

  • 把不变行为搬移到超类，去除子类中的重复代码

观察者模式（Observer）

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己

缺点

  • 抽象通知者还是依赖抽象观察者
  • 通知方法被固定

事件委托

委托就是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。委托可以看作是对函数的抽象，是函数的’类‘，委托的实例将代表一个具体的函数

状态模式（State）

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类

优点

  • 将与特定状态相关的行为局部化，并且将不同状态的行为分割开来
  • 将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换，消除庞大的条件分支语句
  • 状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖

应用

  • 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为

备忘录模式（Memento）

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

应用

  • 适用于功能比较复杂的，但需要维护或记录属性历史的类

命令模式（Command）

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作

优点

  • 把请求一个操作的对象与知道怎么执行一个操作的对象分割开
  • 容易地设计一个命令队列
  • 容易地将命令记入日志
  • 允许接受请求的一方决定是否要否决请求
  • 容易地实现对请求的撤销和重做
  • 增加新的具体命令类很容易

应用

  • 敏捷开发原则告诉我们，不要为代码添加基于猜测的，实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义

迭代器模式（Iterator）

提供一种方法顺序访问一个聚合对象中各个元素，而又不是暴露该对象的内部表示

职责链模式（Chain of Responsibility）

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止

优点

  • 可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用
  • 可随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性

中介者模式（Mediator）

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

优点

  • 减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator
  • 由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统

缺点

  • 由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂

应用

  • 用于一组对象以定义良好但是复杂的方式进行通信的场合
  • 想定制一个分布在多个类中的行为，而又不想生成太多的子类

解释器模式（Interpreter）

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子

应用

  • 当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时

优点

  • 容易地改变和扩展文化，因为该模式使用类来表示文化规则，可使用继承来改变或扩展该文化。也比较容易实现文化，因为定义抽象语法树中各个节点的类的实现大体类似，这些类都易于直接编写

缺点

  • 为文法中的每一条规则至少定义了一个类，因此包含许多规则的方法可能难以管理和维护。建议当文化非常复杂时，使用其他的技术如语法分析程序或编译器生成器来处理

访问者模式（Visitor）

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作