设计模式-行为型模式

原文地址：http://blog.csdn.net/column/details/pattern.html?&page=1

行为型模式

模版方法模式
策略模式
状态模式
命令模式
迭代器模式
备忘录模式
观察者模式
中介者模式
访问者模式
责任链模式
解释器模式

模版方法模式

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

模版模式的核心是一个抽象类。抽象类将实现逻辑的骨架定义好，具体实现的抽象方法有继承的子类去实现。

策略模式

定义：定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。

策略模式与模版模式的区别在于：
在模版方法模式中，调用算法的主体在抽象的父类中，而在策略模式中，调用算法的主体则是封装到了封装类Context中。

状态模式

定义：状态模式允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。

简单地说：一个Context对象的状态会发生改变，在他状态发送改变后，若调用request方法，具体的操作是有目前状态的handle方法来操作的，就如同request方法的发生了变化，换种说法，就如同Context对象看上去是改变了类。

状态模式与策略模式有相似之处，都是把具体的处理逻辑抽象封装出来，区别在于：
状态模式将各个状态所对应的操作分离开来，即对于不同的状态，由不同的子类实现具体操作，不同状态的切换由子类实现，当发现传入参数不是自己这个状态所对应的参数，则自己给Context类切换状态；而策略模式是直接依赖注入到Context类的参数进行选择策略，不存在切换状态的操作。

命令模式

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式的核心在于对命令的封装，即通过将对命令的操作（接受者接口方法的执行顺序等）封装在命令对象的方法中，然后在合适的时间由调用者对象进行调用。调用者Invoker持有一组命令对象的实例。

通过命令对象可以有效降低命令与调用者对于具体操作的耦合，同时可以实现命令的撤销，批量执行等操作。

缺点：过多的简单命令对象创建（几行代码）会造成封装的繁琐。

迭代器模式

定义：提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。

迭代器与集合是密不可分的，它可以在隐藏集合对象的内部实现的情况下提供一种有效的遍历集合的方式。

备忘录模式

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

发起人对象的某一瞬时状态可以用备忘录对象保存（可以是发起人对象的全部或部分属性值），备忘录有管理角色管理（管理角色保存一组备忘录对象的实例）。在需要还原的时候，可以通过获取管理角色中所保管的备忘录对象来还原发起人的状态。

观察者模式

定义：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化，这时候最佳的解决方案既是观察者模式。

观察者模式一个重要点是注册于被观察者中的观察者集合。

中介者模式

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

中介者模式是将多个同事类之间的一对多耦合降低成一对一的星状耦合。一般情况下一对多的依赖在程序设计中是允许的，没有必要引用中介这模式。除非在依赖关系过于复杂的情况下，我们才使用中介者降低耦合。

访问者模式

定义：封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

    abstract class Element {  public abstract void accept(IVisitor visitor);  public abstract void doSomething();  }  interface IVisitor {  public void visit(ConcreteElement1 el1);  public void visit(ConcreteElement2 el2);  }  class ConcreteElement1 extends Element {  public void doSomething(){  System.out.println("这是元素1");  }  public void accept(IVisitor visitor) {  visitor.visit(this);  }  }  class ConcreteElement2 extends Element {  public void doSomething(){  System.out.println("这是元素2");  }  public void accept(IVisitor visitor) {  visitor.visit(this);  }  }  class Visitor implements IVisitor {  public void visit(ConcreteElement1 el1) {  el1.doSomething();  }  public void visit(ConcreteElement2 el2) {  el2.doSomething();  }  }  class ObjectStruture {  public static List<Element> getList(){  List<Element> list = new ArrayList<Element>();  Random ran = new Random();  for(int i=0; i<10; i++){  int a = ran.nextInt(100);  if(a>50){  list.add(new ConcreteElement1());  }else{  list.add(new ConcreteElement2());  }  }  return list;  }  }  public class Client {  public static void main(String[] args){  List<Element> list = ObjectStruture.getList();  for(Element e: list){  e.accept(new Visitor());  }  }  }

访问者模式的优点

符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，符合单一职责原则。
扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

引自原文：

但是，访问者模式并不是那么完美，它也有着致命的缺陷：增加新的元素类比较困难。通过访问者模式的代码可以看到，在访问者类中，每一个元素类都有它对应的处理方法，也就是说，每增加一个元素类都需要修改访问者类（也包括访问者类的子类或者实现类），修改起来相当麻烦。也就是说，在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构，比如说，一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。

最复杂的行为型模式。

责任链模式

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

责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中。

如果if中的判断过于负载就可以使用责任链。

但是使用责任链时一定要注意链的顺序，以及避免出现死循环的情况。

解释器模式

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

基本用不到。