设计模式:观察者模式

观察者模式  


一、引子 
    还记得警匪片上，匪徒们是怎么配合实施犯罪的吗？一个团伙在进行盗窃的时候，总 
有一两个人在门口把风——如果有什么风吹草动，则会立即通知里面的同伙紧急撤退。也许 
放风的人并不一定认识里面的每一个同伙；而在里面也许有新来的小弟不认识这个放风的。 
但是这没什么，这个影响不了他们之间的通讯，因为他们之间有早已商定好的暗号。 
    呵呵，上面提到的放风者、偷窃者之间的关系就是观察者模式在现实中的活生生的例子。 


二、定义与结构 
    观察者（Observer）模式又名发布-订阅（Publish/Subscribe）模式。GOF  给观察者模 
式如下定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依 
赖于它的对象都得到通知并被自动更新。 
    在这里先讲一下面向对象设计的一个重要原则——单一职责原则。系统的每个对象应该 
将重点放在问题域中的离散抽象上。因此理想的情况下，一个对象只做一件事情。这样在开 
发中也就带来了诸多的好处：提供了重用性和维护性，也是进行重构的良好的基础。 
    因此几乎所有的设计模式都是基于这个基本的设计原则来的。观察者模式的起源我觉得 
应该是在GUI 和业务数据的处理上，因为现在绝大多数讲解观察者模式的例子都是这一题 
材。但是观察者模式的应用决不仅限于此一方面。 
    下面我们就来看看观察者模式的组成部分。 
1)  抽象目标角色（Subject）：目标角色知道它的观察者，可以有任意多个观察者观察同一 
    个目标。并且提供注册和删除观察者对象的接口。目标角色往往由抽象类或者接口来实 
    现。 
2)  抽象观察者角色（Observer）：为那些在目标发生改变时需要获得通知的对象定义一个 
    更新接口。抽象观察者角色主要由抽象类或者接口来实现。 
3)  具体目标角色（Concrete Subject）：将有关状态存入各个Concrete Observer 对象。当 
    它的状态发生改变时,  向它的各个观察者发出通知。 
4)  具体观察者角色（Concrete Observer）：存储有关状态，这些状态应与目标的状态保持 
    一致。实现Observer 的更新接口以使自身状态与目标的状态保持一致。在本角色内也 
    可以维护一个指向Concrete Subject 对象的引用。 
    放上观察者模式的类图，这样能将关系清晰的表达出来。 

                         Subject 


                         attach() 
                         dettach() 
                         notify() 
                                                          Observer 
                         getState() 
                         setState() 


                                                             update() 


                    ConcreteSubject 
                    subjectState : int               ConcreteObserver 


                    getState() 
                    setState() 


     在Subject 这个抽象类中，提供了上面提到的功能，而且存在一个通知方法：notify。 
还可以看到Subject 和ConcreteSubject 之间可以说是使用了模板模式（这个模式真是简单 
普遍到一不小心就用到了）。 
     这样当具体目标角色的状态发生改变，按照约定则会去调用通知方法，在这个方法中则 
会根据目标角色中注册的观察者名单来逐个调用相应的update 方法来调整观察者的状态。 
这样观察者模式就走完了一个流程。 


三、举例 
     观察者模式是我在《JUnit 源代码分析》中遗留的一个模式，因此这里将采用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 来作的，而你在 
具体的系统中可以灵活掌握。 
    看一下TestRunner 中的代码： 


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


            result.addListener(fPrinter); 
        …… 


四、使用情况 
    GOF 给出了以下使用观察者模式的情况： 
    1)  当一个抽象模型有两个方面,  其中一个方面依赖于另一方面。将这二者封装在独立 
        的对象中以使它们可以各自独立地改变和复用。 
    2)  当对一个对象的改变需要同时改变其它对象,  而不知道具体有多少对象有待改变。 
    3)  当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之,  你不希望 
        这些对象是紧密耦合的。 


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

则“拉模式”就很合适啦。 

下载：

http://download.csdn.net/detail/undoner/5335717

深入浅出设计模式-中文版

http://www.lsoft.cn

LSOFT.CN (琅软中国) - 创造玉石般的软件,完美的用户体验！