设计模式之观察者模式（Observer）

观察者模式

观察者模式是在一个实体类上面，建立多个观察者，观察者同时监听实体类，当实体类状态发生变化的时候，观察者能够根据实体的变化相应的做出变化。
观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF给观察者模式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

观察者模式组成

1、抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实现。
2、抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个更新接口。抽象观察者角色主要由抽象类或者接口来实现。
3、具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer对象。当它的状态发生改变时, 向它的各个观察者发出通知。
4、具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。在本角色内也可以维护一个指向Concrete Subject对象的引用。

示例如下

引用自http://blog.csdn.net/ai92/article/details/375691
这里将采用JUnit来作为例子，JUnit为用户提供了三种不同的测试结果显示界面，以后还可能会有其它方式的现实界面……。怎么才能将测试的业务逻辑和显示结果的界面很好的分离开？不用问，就是观察者模式！
下面我们来看看JUnit中观察者模式的使用代码：

//下面是我们的抽象观察者角色，JUnit是采用接口来实现的，这也是一般采用的方式。
//可以看到这里面定义了四个不同的update方法，对应四种不同的状态变化
public interface TestListener {
       /**
       * An error occurred.
       */
       public void addError(Test test, Throwable t);
       /**
       * A failure occurred.
       */
      public void addFailure(Test test, AssertionFailedError t); 
       /**
        * A test ended.
        */
      public void endTest(Test test);
       /**
        * A test started.
        */
       public void startTest(Test test);
}

//具体观察者角色，我们采用最简单的TextUI下的情况来说明（AWT，Swing对于整天做Web应用的人来说，已经很陌生了）
public class ResultPrinter implements TestListener {
       //省略好多啊，主要是显示代码
……
       //下面就是实现接口TestListener的四个方法
       //填充方法的行为很简单的说
       /**
        * @see junit.framework.TestListener#addError(Test, Throwable)
        */
       public void addError(Test test, Throwable t) {
              getWriter().print("E");
       }
       /**
        * @see junit.framework.TestListener#addFailure(Test, AssertionFailedError)
        */
       public void addFailure(Test test, AssertionFailedError t) {
              getWriter().print("F");
       }
       /**
        * @see junit.framework.TestListener#endTest(Test)
        */
       public void endTest(Test test) {
       }
       /**
        * @see junit.framework.TestListener#startTest(Test)
        */
       public void startTest(Test test) {
              getWriter().print(".");
              if (fColumn++ >= 40) {
                     getWriter().println();
                     fColumn= 0;
              }
       }
}

来看下我们的目标角色，随便说下，由于JUnit功能的简单，只有一个目标——TestResult，因此JUnit只有一个具体目标角色。

//好长的代码，好像没有重点。去掉了大部分与主题无关的信息
//下面只列出了当Failures发生时是怎么来通知观察者的
public class TestResult extends Object {
       //这个是用来存放测试Failures的集合
protected Vector fFailures;
//这个就是用来存放注册进来的观察者的集合
       protected Vector fListeners;
       public TestResult() {
              fFailures= new Vector();
              fListeners= new Vector();
       }
       /**
        * Adds a failure to the list of failures. The passed in exception
        * caused the failure.
        */
       public synchronized void addFailure(Test test, AssertionFailedError t) {
              fFailures.addElement(new TestFailure(test, t));
              //下面就是通知各个观察者的addFailure方法
              for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ){
                     ((TestListener)e.nextElement()).addFailure(test, t);
              }
       }
       /**
        * 注册一个观察者
        */
       public synchronized void addListener(TestListener listener) {
              fListeners.addElement(listener);
       }
       /**
        * 删除一个观察者
        */
       public synchronized void removeListener(TestListener listener) {
              fListeners.removeElement(listener);
       }
       /**
        * 返回一个观察者集合的拷贝，当然是为了防止对观察者集合的非法方式操作了
     * 可以看到所有使用观察者集合的地方都通过它
        */
       private synchronized Vector cloneListeners() {
              return (Vector)fListeners.clone();
       }
       ……
}

抽象目标角色突出的不是很明显。
嗯，观察者模式组成所需要的角色在这里已经全了。不过好像还是缺点什么……。呵呵，对！就是它们之间还没有真正的建立联系。在JUnit中是通过TestRunner来作的，而你在具体的系统中可以灵活掌握。

public class TestRunner extends BaseTestRunner {
       private ResultPrinter fPrinter;
public TestResult doRun(Test suite, boolean wait) {
//就是在这里注册的
              result.addListener(fPrinter);
……

如下例子更加简单易懂：
定义抽象的观察者：

public interface Watcher
{
    public void update(String str);

}

定义抽象的主题角色，即抽象的被观察者，在其中声明方法（添加、移除观察者，通知观察者）：

//抽象主题角色，watched：被观察
public interface Watched
{
    public void addWatcher(Watcher watcher);

    public void removeWatcher(Watcher watcher);

    public void notifyWatchers(String str);

}

定义具体的观察者：

public class ConcreteWatcher implements Watcher
{
    @Override
    public void update(String str)
    {
        System.out.println(str);
    }
}

具体的主题角色：　

import java.util.ArrayList;
import java.util.List;

public class ConcreteWatched implements Watched
{
    // 存放观察者
    private List<Watcher> list = new ArrayList<Watcher>();

    @Override
    public void addWatcher(Watcher watcher)
    {
        list.add(watcher);
    }

    @Override
    public void removeWatcher(Watcher watcher)
    {
        list.remove(watcher);
    }

    @Override
    public void notifyWatchers(String str)
    {
        // 自动调用实际上是主题进行调用的
        for (Watcher watcher : list)
        {
            watcher.update(str);
        }
    }

}

编写测试类,将观察者注册到目标类中：

public class Test
{
    public static void main(String[] args)
    {
        Watched girl = new ConcreteWatched();

        Watcher watcher1 = new ConcreteWatcher();
        Watcher watcher2 = new ConcreteWatcher();
        Watcher watcher3 = new ConcreteWatcher();

        girl.addWatcher(watcher1);
        girl.addWatcher(watcher2);
        girl.addWatcher(watcher3);

        girl.notifyWatchers("开心");
    }

}

使用情况

观察者模式主要应用在java Swing中，进行许多事件的监听中，例如鼠标的点击行为，键盘的敲击行为等等。
GOF给出了以下使用观察者模式的情况：
1、当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
2、当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
3、当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
其实观察者模式同桥梁模式、策略模式有着共同的使用环境：将变化独立封装起来，以达到最大的重用和解耦。观察者与后两者不同的地方在于，观察者模式中的目标和观察者的变化不是独立的，而是有着某些联系。

具体机制-“我推你拉”

观察者模式在关于目标角色、观察者角色通信的具体实现中，有两个版本。一种情况便是目标角色在发生变化后，仅仅告诉观察者角色“我变化了”；观察者角色如果想要知道具体的变化细节，则就要自己从目标角色的接口中得到。这种模式被很形象的称为：拉模式——就是说变化的信息是观察者角色主动从目标角色中“拉”出来的。
还有一种方法，那就是我目标角色“服务一条龙”，通知你发生变化的同时，通过一个参数将变化的细节传递到观察者角色中去。这就是“推模式”——管你要不要，先给你啦。
这两种模式的使用，取决于系统设计时的需要。如果目标角色比较复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，则“推模式”比较合适。如果目标角色比较简单，则“拉模式”就很合适啦。