程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> JDK Observer設計模式研究

JDK Observer設計模式研究

編輯:關於JAVA

目前設計模式的介紹性文章越來越多,但設計模式的研究性文章仍然比較欠缺,這著實讓人覺得有點遺憾。本文旨在拋磚引玉,具體分析一下java中jdk自帶的observer設計模式(下文如沒特別指出,observer設計模式就意指java中jdk自帶的observer設計模式)的實現。

1.Observer設計模式概要

Observer設計模式在GOF裡屬於行為設計模式。JDK裡提供的observer設計模式的實現由java.util.Observable類和java.util.Observer接口組成。從名字上可以清楚的看出兩者在Observer 設計模式中分別扮演的角色:Observer是觀察者角色,Observable是被觀察目標(subject)角色。

Observable是一個封裝subject基本功能的類,比如注冊observer(attach功能),注銷observer(detatch功能)等。這些功能是任何一個扮演observerable角色的類都需要實現的,從這一點上來講,JDK裡將這些通用功能專門封裝在一個類裡,顯得合情合理。通常情況下,我們的類只要從Observerable類派生就可以稱為observerable角色類,使用非常簡單。

2.使用observer設計模式存在的困難

但我們不得不注意到,在項目實際開發當中,情況往往要復雜得多。java不支持多繼承特性在很多時候是阻礙我們使用observer設計模式的絆腳石。比如說,我們設計的一個類已經是某個類的派生類,在這種情況下同時想讓它扮演observerable角色將變得麻煩。如何實現“多繼承”的效果是擺在我們面前的一大難題。下面我們首先分析一下Observable類。

3.Observable類“觸發通知”的原理

Observable必須“有變化”才能觸發通知observer這一任務,這是它的本質體現。查看源碼便可知一二。Observerable部分源碼如下:

//……省略……
   private boolean changed = false;
   //……省略……
   public void notifyObservers(Object arg) {
   //……省略……
     Object[] arrLocal;
     synchronized (this) {
      //……省略……
      if (!changed)
       return;
       arrLocal = obs.toArray();
       clearChanged();
     }
   //……省略……
   protected synchronized void setChanged() {
    changed = true;
   }

   protected synchronized void clearChanged() {
    changed = false;
   }

正如粗的斜體標注部分所示,在notifyObservers(Object arg) 方法裡if (!changed) return;語句告訴我們,若changed屬性值為false,將直接返回,根本不會觸發通知操作。並且我們注意到changed 屬性被初始化為false,這將意味著如果我們不主動設置changed屬性為true,將不會有任何變化,也就是說根本起不到“通知”作用。因此,設置changed屬性的值是我們應用jdk observer 設計模式的關鍵所在。那麼如何才能設置changed屬性呢?從源碼可以看出,唯一的入口是通過setChanged()。下面我們分析一下changed屬性及相關的方法setChanged()和clearChanged()。

4.Observable類的分析

Observable#changed屬性的初始值為false,這很容易理解,不再詳細陳述。細心的讀者可能會注意到跟changed屬性有關的兩個方法setChanged()和clearChanged(),它們的修飾符都是protected。想強調的是,是protected,而不是public。但這樣是否有其必要性和合理性?答案是肯定的。在前面的分析中,我已經提到,setChanged()方法是設置changed的唯一入口,它的修飾符定義為protected,就意味著通過定義Observable的對象,再設置changed屬性將變得不可能。從這個意義上說,要想應用observer設計模式,必須繼承Observable類方可。關於這一點,下文還會提及。但是,為什麼不能定義成public?這似乎難以理解。因為定義成public,我們不就可以很方便地設置changed屬性的值嗎?為了弄清楚這個問題,我們還是看一下Observable裡的相關的代碼:

//……省略……
   public void notifyObservers(Object arg) {
   //……省略……
    for (int i = arrLocal.length-1; i>=0; i--)
     ((Observer)arrLocal[i]).update(this, arg);
   }
    

 

這段代碼表達的意思是說找出所有已注冊的Observer,再逐個進行“通知”,通過調用Observer#update(Observable,Object)方法進行通知。我們看到,update 第一個參數是this,我們同時還必須注意到,這段代碼是Observable類裡的代碼。這就相當於是在一再強調,發出“通知”的,必須是observable自己(Observable類或者其派生類),其它任何類都不行。這就意味著我們的observable類繼承Observable類是必要的,因為如果不繼承,而采用組合的話,將無法保證能傳遞好this。換句話說,采用組合的方式使用Observable類,將變得幾乎沒有任何意義。同時,修飾符定義為protected,可以確保是在Obsrvable裡進行觸發通知的,不會在其它任何地方進行通知,這顯得內斂性很強。如果將setChanged()修飾符定義為public,將無法保證正確“傳遞this”的硬性要求,這不符合“只有observalbe才能直接或間接通知observer”這一observable設計模式的硬性要求。由此我們可見一斑,jdk的很多理念的思想性是多麼的強。

5.解決使用observer設計模式存在的困難

借助adapter設計模式(詳見本人發表的adapter設計模式相關文章)和java支持多接口特性基本可以解決“多繼承”問題。基本思想是結合繼承/實現和組合來達到效果。在上面的分析中,我們已經知道,Observable類必須繼承使用,不能組合使用,因此我們只需要將需扮演成observerable角色的類裝扮成adapter角色,將該類原繼承的類裝扮成adaptee角色即可。示例代碼如下:

//欲充當observable角色的類的原來的代碼:
   public class MyObject extends BaseObject {
    public MyObject() {
     public void method1(){}
    }
   }
   //充當observable角色後的代碼:
   public class MyObject extends Observable {
    private BaseObject baseObject = null;
     public MyObject(BaseObject baseObject) {
      this.baseObject = baseObject;
     }
   }

6.注意事項:

如果上例中的BaseObject也用到需要傳遞“this”的方法,那麼上面的組合使用方法將有可能失效。這種情況是最糟糕的情況。此時可以考慮在BaseObject類這些“瓶頸”地方盡量采用接口代替類(包括抽象類)來解決。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved