设计模式:观察者模式

观察者模式  


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


二、定义与结构 
    观察者(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 (琅软中国) - 创造玉石般的软件,完美的用户体验!


你可能感兴趣的:(软件工程)