By HamletDRC
via tv.jetbrains.net
Published: Feb 25 2011 / 12:03
![]() | |
| NoSQL Scalability | |
| Written by: Eugene Ciurana | |
| Featured Refcardz: Top Refcardz: | |
| 150+ Refcardz Available · Get them all | |
By HamletDRC
via tv.jetbrains.net
Published: Feb 25 2011 / 12:03
Comments
iirekm replied ago:
I had a chance to use such event buses in one project and I have to say that I'm dissatisfied. This event bus you've shown is just an example of Observer pattern, the difference is that 'fireXXXEvent', 'addXXXListener' was moved to an object called 'SimpleEventBus'. Unfortunately it has problems:
1) By moving all event listeners to one object (event bus), you have to remember to call 'removeXXXListener' every time a GUI control is removed from the screen, otherwise you may get memory leaks, as objects on the screen appear and disappear if you have complex GUI (ie where GWT is best). This is not a problem for 'enterprise' buses (eg ESB), where modules don't appear that often, but may be a problem for such 'small' buses.
With 'normal' observer pattern each object has its own list of listeners, and in most cases can rely on garbage collector to deallocate memory for you.
2) Observer pattern is self-documenting: when a class has 'addClickListener' and 'addValueChangeListener' it's clear, that it sends 'click' and 'value change' events. This isn't that clear with event bus (unless you explicitly state in Javadocs what events can be thrown).
3) While the design you've shown is quite pretty (because it's just a variation of Observer pattern), the market-leading event bus designs for GWT (eg mvp4g, and others) are just terrible.
hamletatcanoo replied ago:
These are good points. My thoughts...
1) You *do* need to remove listeners with an event bus or you may get memory leaks. True and good criticism.
2) What I like about Event Buses is that you don't need to re implement a Subject/Observer into every one of your MVC groups. I think if you tried to create an abstraction over many observers then you'd probably end up with something like an event bus. In my experience, the benefits of event buses outweigh the costs.
3) I have only used the GWT Event Bus, and the team I was on was really happy with it. We had a very complex GUI with lots of animations and "when this happens then this other thing occurs" style effects, and we were really happy with the results of using the GWT event bus. I see that GWT MVP is getting popular but I haven't had the chance to try it.
Thanks for the feedback, these are interesting points.
iirekm replied ago:
[you don't need to re implement a Subject/Observer into every one of your MVC groups]
Yes, the way people typically do listeners in Java is ugly (you have to implement 'listeners' field and add/remove/fire methods). You can do instead:
- add extends EventBase (or something like that); it contains addListener/removeListener/fireEvent methods, but you can't tell what events are raised by just reading method names (addXXXXListener, addYYYYListener has become addListener)
- do something C#-like: event MyEventType eventName. For example in Scala I could do this as: val eventName = new EventListeners[MyEventType], in Java it would be more writing, but is still better than the addXXXXListener/removeXXXXListener/fireXXXXEvent, which was just "inherited" from the agy JavaBeans specification
[I have only used the GWT Event Bus, and the team I was on was really happy with it]
You were lucky you weren't using mvp4g: annotations, kinda reflection (xxxx -> onXxxx), event propagation rules, modules - it makes a real monster from code. :-)
hamletatcanoo replied ago:
I understand extending EventBase, but it is a suboptimal solution for me because it requires implementation inheritance. I think the Griffon Event System is very good, and I am making a screencast about it today or tomorrow. (yea it's an event system screen cast round up). With Griffon the event keys are just Strings and event handlers are named closures on a controller. It is very slick, as Griffon handles registry and unregistry for you.
Voters For This Link (24)
Voters Against This Link (0)