设计模式之行为类模式

参考原文

概述

观察者模式

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

观察者模式的结构

• 被观察者：从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。
• 观察者：观察者角色一般是一个接口，它只有一个update方法，在被观察者状态发生变化时，这个方法就会被触发调用。
• 具体的被观察者：使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
• 具体的观察者：观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。

观察者代码实现

abstract class Subject {    private Vector<Observer> obs = new Vector<Observer>();    public void addObserver(Observer obs){        this.obs.add(obs);    }    public void delObserver(Observer obs){        this.obs.remove(obs);    }    protected void notifyObserver(){        for(Observer o: obs){            o.update();        }    }    public abstract void doSomething();}class ConcreteSubject extends Subject {    public void doSomething(){        System.out.println("被观察者事件反生");        this.notifyObserver();    }}interface Observer {    public void update();}class ConcreteObserver1 implements Observer {    public void update() {        System.out.println("观察者1收到信息，并进行处理。");    }}class ConcreteObserver2 implements Observer {    public void update() {        System.out.println("观察者2收到信息，并进行处理。");    }}public class Client {    public static void main(String[] args){        Subject sub = new ConcreteSubject();        sub.addObserver(new ConcreteObserver1()); //添加观察者1        sub.addObserver(new ConcreteObserver2()); //添加观察者2        sub.doSomething();    }}

运行结果：

被观察者事件反生
观察者1收到信息，并进行处理。
观察者2收到信息，并进行处理。

通过运行结果可以看到，我们只调用了Subject的方法，但同时两个观察者的相关方法都被同时调用了。仔细看一下代码，其实很简单，无非就是在Subject类中关联一下Observer类，并且在doSomething方法中遍历一下Observer的update方法就行了。

观察者模式的优点
观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。
观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。

总结
java语言中，有一个接口Observer，以及它的实现类Observable，对观察者角色常进行了实现。我们可以在jdk的api文档具体查看这两个类的使用方法。
做过VC++、javascript DOM或者AWT开发的朋友都对它们的事件处理感到神奇，了解了观察者模式，就对事件处理机制的原理有了一定的了解了。如果要设计一个事件触发处理机制的功能，使用观察者模式是一个不错的选择，AWT中的事件处理DEM（委派事件模型Delegation Event Model）就是使用观察者模式实现的。

模板方法

转载

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

事实上，模版方法是编程中一个经常用到的模式。先来看一个例子，某日，程序员A拿到一个任务：给定一个整数数组，把数组中的数由小到大排序，然后把排序之后的结果打印出来。经过分析之后，这个任务大体上可分为两部分，排序和打印，打印功能好实现，排序就有点麻烦了。但是A有办法，先把打印功能完成，排序功能另找人做。

abstract class AbstractSort {    /**     * 将数组array由小到大排序     * @param array     */    protected abstract void sort(int[] array);    public void showSortResult(int[] array){        this.sort(array);        System.out.print("排序结果：");        for (int i = 0; i < array.length; i++){            System.out.printf("%3s", array[i]);        }    }}

写完后，A找到刚毕业入职不久的同事B说：有个任务，主要逻辑我已经写好了，你把剩下的逻辑实现一下吧。于是把AbstractSort类给B，让B写实现。B拿过来一看，太简单了，10分钟搞定，代码如下：

class ConcreteSort extends AbstractSort {    @Override    protected void sort(int[] array){        for(int i=0; i<array.length-1; i++){            selectSort(array, i);        }    }    private void selectSort(int[] array, int index) {        int MinValue = 32767; // 最小值变量        int indexMin = 0; // 最小值索引变量        int Temp; // 暂存变量        for (int i = index; i < array.length; i++) {            if (array[i] < MinValue){ // 找到最小值                MinValue = array[i]; // 储存最小值                indexMin = i;             }        }        Temp = array[index]; // 交换两数值        array[index] = array[indexMin];        array[indexMin] = Temp;    }}

写好后交给A，A拿来一运行：

public class Client {      public static int[] a = { 10, 32, 1, 9, 5, 7, 12, 0, 4, 3 }; // 预设数据数组      public static void main(String[] args){          AbstractSort s = new ConcreteSort();          s.showSortResult(a);      }  }  

运行结果：
排序结果： 0 1 3 4 5 7 9 10 12 32

运行正常。行了，任务完成。没错，这就是模版方法模式。大部分刚步入职场的毕业生应该都有类似B的经历。一个复杂的任务，由公司中的牛人们将主要的逻辑写好，然后把那些看上去比较简单的方法写成抽象的，交给其他的同事去开发。这种分工方式在编程人员水平层次比较明显的公司中经常用到。比如一个项目组，有架构师，高级工程师，初级工程师，则一般由架构师使用大量的接口、抽象类将整个系统的逻辑串起来，实现的编码则根据难度的不同分别交给高级工程师和初级工程师来完成。怎么样，是不是用到过模版方法模式？

模版方法模式的结构

模版方法模式由一个抽象类和一个（或一组）实现类通过继承结构组成，抽象类中的方法分为三种：

• 抽象方法：父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
• 模版方法：由抽象类声明并加以实现。一般来说，模版方法调用抽象方法来完成主要的逻辑功能，并且，模版方法大多会定义为final类型，指明主要的逻辑功能在子类中不能被重写。
• 钩子方法：由抽象类声明并加以实现。但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。
• 抽象类的任务是搭建逻辑的框架，通常由经验丰富的人员编写，因为抽象类的好坏直接决定了程序是否稳定性。

实现类用来实现细节。抽象类中的模版方法正是通过实现类扩展的方法来完成业务逻辑。只要实现类中的扩展方法通过了单元测试，在模版方法正确的前提下，整体功能一般不会出现大的错误。

模版方法的优点及适用场景

容易扩展。一般来说，抽象类中的模版方法是不易反生改变的部分，而抽象方法是容易反生变化的部分，因此通过增加实现类一般可以很容易实现功能的扩展，符合开闭原则。
便于维护。对于模版方法模式来说，正是由于他们的主要逻辑相同，才使用了模版方法，假如不使用模版方法，任由这些相同的代码散乱的分布在不同的类中，维护起来是非常不方便的。
比较灵活。因为有钩子方法，因此，子类的实现也可以影响父类中主逻辑的运行。但是，在灵活的同时，由于子类影响到了父类，违反了里氏替换原则，也会给程序带来风险。这就对抽象类的设计有了更高的要求。
在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。

命令模式

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

类图：

命令模式的结构
顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：

• Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
• ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
• Client类：最终的客户端调用类。
  以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。
• Invoker类：调用者，负责调用命令。

• Receiver类：接收者，负责接收命令并且执行命令。

  所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？
  其实大家可以换一个角度去想：假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。命令模式的通用代码如下：

class Invoker {    private Command command;    public void setCommand(Command command) {        this.command = command;    }    public void action(){        this.command.execute();    }}abstract class Command {    public abstract void execute();}class ConcreteCommand extends Command {    private Receiver receiver;    public ConcreteCommand(Receiver receiver){        this.receiver = receiver;    }    public void execute() {        this.receiver.doSomething();    }}class Receiver {    public void doSomething(){        System.out.println("接受者-业务逻辑处理");    }}public class Client {    public static void main(String[] args){        Receiver receiver = new Receiver();        Command command = new ConcreteCommand(receiver);        //客户端直接执行具体命令方式（此方式与类图相符）        command.execute();        //客户端通过调用者来执行命令        Invoker invoker = new Invoker();        invoker.setCommand(command);        invoker.action();    }}

通过代码我们可以看到，当我们调用时，执行的时序首先是调用者类，然后是命令类，最后是接收者类。也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。

命令模式的优缺点
首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。
其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。
最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

命令模式的适用场景
对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

总结
对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。
拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。

迭代器模式

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

如果要问java中使用最多的一种模式，答案不是单例模式，也不是工厂模式，更不是策略模式，而是迭代器模式，先来看一段代码吧：

public static void print(Collection coll){    Iterator it = coll.iterator();    while(it.hasNext()){        String str = (String)it.next();        System.out.println(str);    }}

这个方法的作用是循环打印一个字符串集合，里面就用到了迭代器模式，java语言已经完整地实现了迭代器模式，Iterator翻译成汉语就是迭代器的意思。提到迭代器，首先它是与集合相关的，集合也叫聚集、容器等，我们可以将集合看成是一个可以包容对象的容器，例如List，Set，Map，甚至数组都可以叫做集合，而迭代器的作用就是把容器中的对象一个一个地遍历出来。

迭代器模式的结构

• 抽象容器：一般是一个接口，提供一个iterator()方法，例如java中的Collection接口，List接口，Set接口等。
• 具体容器：就是抽象容器的具体实现类，比如List接口的有序列表实现ArrayList，List接口的链表实现LinkList，Set接口的哈希列表的实现HashSet等。
• 抽象迭代器：定义遍历元素所需要的方法，一般来说会有这么三个方法：取得第一个元素的方法first()，取得下一个元素的方法next()，判断是否遍历结束的方法isDone()（或者叫hasNext()），移出当前对象的方法remove(),

代码实现

interface Iterator {    public Object next();    public boolean hasNext();}class ConcreteIterator implements Iterator{    private List list = new ArrayList();    private int cursor =0;    public ConcreteIterator(List list){        this.list = list;    }    public boolean hasNext() {        if(cursor==list.size()){            return false;        }        return true;    }    public Object next() {        Object obj = null;        if(this.hasNext()){            obj = this.list.get(cursor++);        }        return obj;    }}interface Aggregate {    public void add(Object obj);    public void remove(Object obj);    public Iterator iterator();}class ConcreteAggregate implements Aggregate {    private List list = new ArrayList();    public void add(Object obj) {        list.add(obj);    }    public Iterator iterator() {        return new ConcreteIterator(list);    }    public void remove(Object obj) {        list.remove(obj);    }}public class Client {    public static void main(String[] args){        Aggregate ag = new ConcreteAggregate();        ag.add("小明");        ag.add("小红");        ag.add("小刚");        Iterator it = ag.iterator();        while(it.hasNext()){            String str = (String)it.next();            System.out.println(str);        }    }}

上面的代码中，Aggregate是容器类接口，大家可以想象一下Collection，List，Set等，Aggregate就是他们的简化版，容器类接口中主要有三个方法：添加对象方法add、删除对象方法remove、取得迭代器方法iterator。Iterator是迭代器接口，主要有两个方法：取得迭代对象方法next，判断是否迭代完成方法hasNext，大家可以对比java.util.List和java.util.Iterator两个接口自行思考。

迭代器模式的优缺点
迭代器模式的优点有：

• 简化了遍历方式，对于对象集合的遍历，还是比较麻烦的，对于数组或者有序列表，我们尚可以通过游标来取得，但用户需要在对集合了解很清楚的前提下，自行遍历对象，但是对于hash表来说，用户遍历起来就比较麻烦了。而引入了迭代器方法后，用户用起来就简单的多了。
• 可以提供多种遍历方式，比如说对有序列表，我们可以根据需要提供正序遍历，倒序遍历两种迭代器，用户用起来只需要得到我们实现好的迭代器，就可以方便的对集合进行遍历了。
• 封装性良好，用户只需要得到迭代器就可以遍历，而对于遍历算法则不用去关心。
  迭代器模式的缺点：
• 对于比较简单的遍历（像数组或者有序列表），使用迭代器方式遍历较为繁琐，大家可能都有感觉，像ArrayList，我们宁可愿意使用for循环和get方法来遍历集合。

迭代器模式的适用场景
迭代器模式是与集合共生共死的，一般来说，我们只要实现一个集合，就需要同时提供这个集合的迭代器，就像java中的Collection，List、Set、Map等，这些集合都有自己的迭代器。假如我们要实现一个这样的新的容器，当然也需要引入迭代器模式，给我们的容器实现一个迭代器。
但是，由于容器与迭代器的关系太密切了，所以大多数语言在实现容器的时候都给提供了迭代器，并且这些语言提供的容器和迭代器在绝大多数情况下就可以满足我们的需要，所以现在需要我们自己去实践迭代器模式的场景还是比较少见的，我们只需要使用语言中已有的容器和迭代器就可以了。

策略模式

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

策略模式是对算法的封装，把一系列的算法分别封装到对应的类中，并且这些类实现相同的接口，相互之间可以替换。在前面说过的行为类模式中，有一种模式也是关注对算法的封装——模版方法模式，对照类图可以看到，策略模式与模版方法模式的区别仅仅是多了一个单独的封装类Context，它与模版方法模式的区别在于：在模版方法模式中，调用算法的主体在抽象的父类中，而在策略模式中，调用算法的主体则是封装到了封装类Context中，抽象策略Strategy一般是一个接口，目的只是为了定义规范，里面一般不包含逻辑。其实，这只是通用实现，而在实际编程中，因为各个具体策略实现类之间难免存在一些相同的逻辑，为了避免重复的代码，我们常常使用抽象类来担任Strategy的角色，在里面封装公共的代码，因此，在很多应用的场景中，在策略模式中一般会看到模版方法模式的影子。

策略模式的结构

• 封装类：也叫上下文，对策略进行二次封装，目的是避免高层模块对策略的直接调用。
• 抽象策略：通常情况下为一个接口，当各个实现类中存在着重复的逻辑时，则使用抽象类来封装这部分公共的代码，此时，策略模式看上去更像是模版方法模式。

代码实现

interface IStrategy {    public void doSomething();}class ConcreteStrategy1 implements IStrategy {    public void doSomething() {        System.out.println("具体策略1");    }}class ConcreteStrategy2 implements IStrategy {    public void doSomething() {        System.out.println("具体策略2");    }}class Context {    private IStrategy strategy;    public Context(IStrategy strategy){        this.strategy = strategy;    }    public void execute(){        strategy.doSomething();    }}public class Client {    public static void main(String[] args){        Context context;        System.out.println("-----执行策略1-----");        context = new Context(new ConcreteStrategy1());        context.execute();        System.out.println("-----执行策略2-----");        context = new Context(new ConcreteStrategy2());        context.execute();    }}

策略模式的优缺点
策略模式的主要优点有：

• 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
• 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
• 避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，在上一篇文章中我们已经提到，使用多重条件判断是非常不容易维护的。
  策略模式的缺点主要有两个：
• 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。

适用场景
做面向对象设计的，对策略模式一定很熟悉，因为它实质上就是面向对象中的继承和多态，在看完策略模式的通用代码后，我想，即使之前从来没有听说过策略模式，在开发过程中也一定使用过它吧？至少在在以下两种情况下，大家可以考虑使用策略模式，

• 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
• 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
  策略模式是一种简单常用的模式，我们在进行开发的时候，会经常有意无意地使用它，一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。

责任链模式

访问模式

解释器模式

中介者模式

备忘录模式

状态模式