Java中JDK自帶的JDK Observer設計模式的實現是一個范例，有助于我們在設計模式的思維上有所突破。目前設計模式的介紹性文章越來越多，但設計模式的研究性文章仍然比較欠缺，這著實讓人覺得有點遺憾。本文旨在拋磚引玉。

1.JDK Observer設計模式概要

JDK 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.使用JDK Observer設計模式存在的困難

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

3.JDK 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.JDK Observer注意事項：

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

那么JDK Observer設計模式就介紹到這里，但是很多的設計模式的思路還是要舉一反三慢慢提高。

【編輯推薦】

1. JDK1.6在LINUX下的安裝配置
2. JDK1.5中新的語言特征淺析
3. 在JDK7 b50中將實現正則表達式命名捕獲組
4. JDK日志框架介紹及其主要功能淺析
5. JDK日志框架之自定義日志Handler淺析