blog 版： http://blog.dontcareabout.us/2014/05/handlermanager-event-package.html BBS 版（大抵上）用 markdown 語法撰寫 ______________________________________________________________________ 我大概是當完兵之後才開始用 `HandlerManager` 作 event bus， 目的當然是降低耦合度。 起手 reference 是 tkcn 的這篇 《[利用 HandlerManager 實作共用的 Event Bus][tkcn ref]》， 然後一直以來就爽爽用，沒出啥問題、也沒想過會出問題。 今天在 review 別人的 code 才知道有 `SimpleEventBus`， 然後想知道這兩個到底有什麼差別、該用哪一個比較好？ 沒想到才剛打開 `HandlerManager` 的 source code， 一開頭的 javadoc 就開始噴血： application developers are strongly discouraged from using a HandlerManager instance as a global event dispatch mechanism. WTF？不但不建議，而且是強烈不建議？ GWT MVP 的文件都還是教用 `HandlerManager` 阿？ [tkcn ref]: http://tkcnandy.blogspot.tw/2009/12/ handlermanager-event-bus.html tkcn 建議我去找這段 javadoc 是什麼時候改的， 於是考古了一下，發現 `HandlerManager` 是 2008.11.18 建的， 然後上頭那段恐嚇文字是 2010.12.03 才加上去的 （[HandlerManager log]）。 [HandlerManager log]: https://gwt.googlesource.com/gwt/+/ 58c04717a6ec18dd65adda0e3b6b6a624a3b7ca5%5E%21/#F0 這下子就跑出另一個問題了：「為什麼？」 `HandlerManager` 裡頭還不是用了一個繼承 `SimpleEventBus` 的 `Bus` 然後以此 delegate...... 等等，有兩個 `SimpleEventBus`？ 一個是來自 `com.google.gwt.event.shared`（以下簡稱 `gwt.event`）， 一個是來自 `com.google.web.bindery.event.shared` （以下簡稱 `bindery.event`）。 `gwt.event` 的 `SimpleEventBus` 還是有一個 `bindery.event` 的 `SimpleEventBus` 的 instance（變數名稱為 `real`）。 以 `fireEvent()` 來說，如果要 fire 的 event 是 `bindery.event` 的 `Event` 就用 `real` 來處理， 如果要 fire 的 event 是 `GwtEvent`（在 `gwt.event` 下）， 則改呼叫 （`gwt.event`）`EventBus.castFireEvent()`。 `castFireEvent()` 的程式碼感覺單純 protected void castFireEvent(GwtEvent<?> event) { try { fireEvent((Event<?>) event); } catch (com.google.web.bindery.event.shared.UmbrellaException e) { throw new UmbrellaException(e.getCauses()); } } `GwtEvent` 一樣也是繼承 `Event`， 帳面上看起來根本不會有炸 exception 的可能？ 而且最後還是呼叫 `bindery.event` 的那個 `fireEvent()`， 也就是說，不管怎樣最後處理的都是那個 `bindery.event` 的 `SimpleEventBus`（變數 `real`）。 這一切到底有什麼意義？ 從 `gwt.event` 的 `SimpleEventBus` 看起來： Wraps {com.google.web.bindery.event.shared.SimpleEventBus} for legacy compatibility. `bindery.event` 下的 class 應該都是歷史的眼淚。 甚至 `gwt.event` 的 `EventBus.fireEvent(Event<?>)` 還會 炸有下列訊息的 `UnsupportedOperationException`： Subclass responsibility. This class is a legacy wrapper for com.google.web.bindery.event.shared.EventBus. Use that directly, or try com.google.gwt.event.shared.SimpleEventBus 先面有提到，`SimpleEventBus` 有 override 掉，所以用起來也沒事情。 這樣看起來 `gwt.event` 底下才是未來， `bindery.event` 只是忘記還沒法拋棄的舊情人。 正當一切都覺得很踏實的時候，`GwtEvent` 的 javadoc 馬上來了一記回馬槍： There is no need for an application's custom event types to extend GwtEvent. Prefer {@link Event} instead. 既然建議改用（`bindery.event`）`Event`， 那 `gwt.event` 的那個 `EventBus.fireEvent(Event<?>)` 為什麼又要預設這種行為？ 你為什麼要讓他留在 `bindery.event` 的 package 底下？ 整理到這邊，我就放棄了 [死]。 ### 不負責任的結論 ### 截至目前（2.6.1）的版本看來， 要不要繼續用 `HandlerManager`、`GwtEvent` 還是 `bindery.event` 下的東西， 學理上都不會出事、效果也幾乎一模一樣。 至於 package 分割的方式、未來這個部份會不會有所改變 （謎之聲：應該不會），那等炸了再說吧...... 說不定就算寫信去問 GWT 委員會，他們也都忘記有這件事了...... ### 順便佔篇幅的附錄 ### `bindery.event` 的 `Event.Type` 的 `hashCode` 是這樣來的： private static int nextHashCode; private final int index; public Type() { index = ++nextHashCode; } public final int hashCode() { return index; } 實際上效率應該會不錯，無論是用它當 key 取出對應的 handler 們、 還是 new 一個新的 type、 單純看 event / handler 的實做 code 也都很 Java。 不過底層的 code 用 Java 的角度大概會被詰譙到死 （連個 synchronized 都沒有是哪招？）。 只能說 GWT 寫起來還是並不完全等同 Java， 在看不到的底層就可以用、也應該要用 JS 的思維亂來 XDDD -- 錢鍾書： 說出來的話 http://www.psmonkey.org 比不上不說出來的話 Java 版 cookcomic 版 只影射著說不出來的話 and more...... --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.61.165.57 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1400200898.A.A92.html