22.3 觀察者模式的應用 22.3.1 觀察者模式的優點 ● 觀察者和被觀察者之間是抽象耦合 如此設計，則不管是增加觀察者還是被觀察者都非常容易擴展，而且在Java中都已經實現的抽象層級的定義，在系統擴展方面更是得心應手。 ● 建立一套觸發機制 根據單一職責原則，每個類的職責是單一的，那么怎么把各個單一的職責串聯成真實世界的復雜的邏輯關系呢？比如，我們去打獵，打死了一只母鹿，母鹿有三個幼崽，因失去了母鹿而餓死，尸體又被兩只禿鷹爭搶，因分配不均，禿鷹開始斗毆，然后羸弱的禿鷹死掉，生存下來的禿鷹，則因此擴大了地盤……這就是一個觸發機制，形成了一個觸發鏈。觀察者模式可以完美地實現這里的鏈條形式。 22.3.2 觀察者模式的缺點 觀察者模式需要考慮一下開發效率和運行效率問題，一個被觀察者，多個觀察者，開發和調試就會比較復雜，而且在Java中消息的通知默認是順序執行，一個觀察者卡殼，會影響整體的執行效率。在這種情況下，一般考慮采用異步的方式。 多級觸發時的效率更是讓人擔憂，大家在設計時注意考慮。 22.3.3 觀察者模式的使用場景 ● 關聯行為場景。需要注意的是，關聯行為是可拆分的，而不是“組合”關系。 ● 事件多級觸發場景。 ● 跨系統的消息交換場景，如消息隊列的處理機制。 22.3.4 觀察者模式的注意事項 使用觀察者模式也有以下兩個重點問題要解決。 ● 廣播鏈的問題 如果你做過數據庫的觸發器，你就應該知道有一個觸發器鏈的問題，比如表A上寫了一個觸發器，內容是一個字段更新后更新表B的一條數據，而表B上也有個觸發器，要更新表C，表C也有觸發器……完蛋了，這個數據庫基本上就毀掉了！我們的觀察者模式也是一樣的問題，一個觀察者可以有雙重身份，既是觀察者，也是被觀察者，這沒什么問題呀，但是鏈一旦建立，這個邏輯就比較復雜，可維護性非常差，根據經驗建議，在一個觀察者模式中最多出現一個對象既是觀察者也是被觀察者，也就是說消息最多轉發一次（傳遞兩次），這還是比較好控制的。 注意　它和責任鏈模式的最大區別就是觀察者廣播鏈在傳播的過程中消息是隨時更改的，它是由相鄰的兩個節點協商的消息結構；而責任鏈模式在消息傳遞過程中基本上保持消息不可變，如果要改變，也只是在原有的消息上進行修正。 ● 異步處理問題 這個EJB是一個非常好的例子，被觀察者發生動作了，觀察者要做出回應，如果觀察者比較多，而且處理時間比較長怎么辦？那就用異步唄，異步處理就要考慮線程安全和隊列的問題，這個大家有時間看看Message Queue，就會有更深的了解。