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/cn.aspx?n=bbs/java/M.1400200898.A.A92.html