22.4 觀察者模式的擴展 22.4.1 Java世界中的觀察者模式 細心的你可能已經發現，HanFeiZi這個實現類中應該抽象出一個父類，父類完全作為被觀察者的職責，每一個被觀察者只實現自己的邏輯方法就可以了，如此則非常符合單一職責原則。是的，確實是應該這樣。幸運的是，Java從一開始誕生就提供了一個可擴展的父類，即java.util.Observable，這個類就是為那些“暴露狂”準備的，他們老是喜歡把自己的狀態變更讓別人去欣賞，去觸發，這正符合了我們現在的要求，要把韓非子的所有活動都暴露出去，并且想暴露給誰就暴露給誰。我們打開Java的幫助文件看看，查找一下Observable是不是已經有這個類了？JDK中提供了:java.util.Observable實現類和java.util.Observer接口，也就是說我們上面寫的那個例子中的Observable接口可以改換成java.util.Observale實現類了，如圖22-6所示。  圖22-6 Java中的觀察者類圖 是不是又簡單了很多？那就對了！然后我們看一下我們程序的變更，先看HanFeiZi的實現類，如代碼清單22-20所示。 代碼清單22-20 優化后的被觀察者 public?class?HanFeiZi?extends?Observable,IHanFeiZi{ ?????//韓非子要吃飯了 ?????public?void?haveBreakfast(){ ?????????????System.out.println("韓非子：開始吃飯了..."); ?????????????//通知所有的觀察者 ?????????????super.setChanged(); ?????????????super.notifyObservers("韓非子在吃飯"); ?????} ?????//韓非子開始娛樂了 ?????public?void?haveFun(){ ?????????????System.out.println("韓非子：開始娛樂了..."); ?????????????super.setChanged(); ?????????????this.notifyObservers("韓非子在娛樂"); ?????} } 改變得不多，引入了一個java.util.Observable對象，刪除了增加、刪除觀察者的方法，簡單了很多，那我們再來看觀察者的實現類，如代碼清單22-21所示。 代碼清單22-21 優化后的觀察者 public?class?LiSi?implements?Observer{ ?????//首先李斯是個觀察者，一旦韓非子有活動，他就知道，他就要向老板匯報 ?????public?void?update(Observable?observable,Object?obj){ ?????????????System.out.println("李斯：觀察到韓非子活動，開始向老板匯報了..."); ?????????????this.reportToQinShiHuang(obj.toString()); ?????????????System.out.println("李斯：匯報完畢...\n"); ?????} ?????//匯報給秦始皇 ?????private?void?reportToQinShiHuang(String?reportContext){ ?????????????System.out.println("李斯：報告，秦老板！韓非子有活動了--->"+reportContext); ?????} } 只改變了粗體部分，應java.util.Observer接口要求update傳遞過來兩個變量，Observable這個變量我們沒用到（接口中定義必須實現的），就不處理了。其他兩個觀察者實現類也是相同的改動，不再贅述。 場景類沒有改動，運行結果也完全相同，大家看看我們使用了Java提供的觀察者模式后是不是簡單了很多，所以在Java的世界里橫行時，多看看API，有幫助很大，很多東西Java已經幫你設計了一個良好的框架。 22.4.2 項目中真實的觀察者模式 為什么要說“真實”呢？因為我們剛剛講的那些是太標準的模式了，在系統設計中會對觀察者模式進行改造或改裝，主要在以下3個方面。 ● 觀察者和被觀察者之間的消息溝通 被觀察者狀態改變會觸發觀察者的一個行為，同時會傳遞一個消息給觀察者，這是正確的，在實際中一般的做法是：觀察者中的update方法接受兩個參數，一個是被觀察者，一個是DTO（Data Transfer Object，據傳輸對象），DTO一般是一個純潔的JavaBean,由被觀察者生成，由觀察者消費。 當然，如果考慮到遠程傳輸，一般消息是以XML格式傳遞。 ● 觀察者響應方式 我們這樣來想一個問題，觀察者是一個比較復雜的邏輯，它要接受被觀察者傳遞過來的信息，同時還要對他們進行邏輯處理，在一個觀察者多個被觀察者的情況下，性能就需要提到日程上來考慮了，為什么呢？如果觀察者來不及響應，被觀察者的執行時間是不是也會被拉長？那現在的問題就是：觀察者如何快速響應？有兩個辦法：一是采用多線程技術，甭管是被觀察者啟動線程還是觀察者啟動線程，都可以明顯地提高系統性能，這也就是大家通常所說的異步架構；二是緩存技術，甭管你誰來，我已經準備了足夠的資源給你了，我保證快速響應，這當然也是一種比較好方案，代價就是開發難度很大，而且壓力測試要做的足夠充分，這種方案也就是大家說的同步架構。 ● 被觀察者盡量自己做主 這是什么意思呢？被觀察者的狀態改變是否一定要通知觀察者呢？不一定吧，在設計的時候要靈活考慮，否則會加重觀察者的處理邏輯，一般是這樣做的，對被觀察者的業務邏輯doSomething方法實現重載，如增加一個doSomething(boolean isNotifyObs)方法，決定是否通知觀察者，而不是在消息到達觀察者時才判斷是否要消費。 22.4.3 訂閱發布模型 觀察者模式也叫做發布/訂閱模型（Publish/Subscribe），如果你做過EJB（Enterprise JavaBean）的開發，這個你絕對不會陌生。EJB2是個折騰死人不償命的玩意兒，寫個Bean要實現，還要繼承，再加上那一堆的配置文件，小項目還湊合，你要知道用EJB開發的基本上都不是小項目，到最后是每個項目成員都在罵EJB這個忽悠人的東西；但是EJB3是個非常優秀的框架，還是算比較輕量級，寫個Bean只要加個Annotaion就成了，配置文件減少了，而且也引入了依賴注入的概念，雖然只是EJB2的翻版，但是畢竟還是前進了一步。在EJB中有3個類型的Bean: Session Bean、Entity Bean和MessageDriven Bean，我們這里來說一下MessageDriven Bean（一般簡稱為MDB），消息驅動Bean，消息的發布者（Provider）發布一個消息，也就是一個消息驅動Bean，通過EJB容器（一般是Message Queue消息隊列）通知訂閱者做出回應，從原理上看很簡單，就是觀察者模式的升級版，或者說是觀察則模式的BOSS版。