Building a client-side swing application what should be notified on a bus (application-wide message system, similar in concept to JMS but much simpler) and what should be notified using direct listeners?
When using a bus, I always have an unescapable feeling of ‘I have no idea who uses that and where’. Also, no set order, hard to veto events, hard to know exactly what’s going on at a set time.
On the other hand, using listeners means either directly referencing the source object (coupling) or passing the reference through myriad conversions (A–b_listener–>B, B–c_listener–>C only because a needs to know something only C can to tell, but B has no interest in).
So, are there any rule of the thumb regarding this? Any suggestion how to balance?
Event buses are very, very useful tools for providing decoupling in certain architectures. Listeners are easy to implement, but they have significant limitations when your object and dependency graph gets large. Listeners tend to run into problems with cyclic dependencies (events can ‘bounce’ in odd ways, and you wind up having to play games to ensure that you don’t get stuck. Most binding frameworks do this for you, but there’s something distasteful about knowing that listener events are shooting off into a million places).
I make this kind of decision based on project size and scalability. If it’s a big app, or there are aspects of the app that can by dynamic (like plugin modules, etc…) then a bus is a good way to keep the architecture clean (OSGI-like module containers are another approach, but heavier weight).
If you are considering a bus architecture, I recommend that you take a look at the Event Bus project – it works very well with Swing and provides a robust, out of the box solution for what you are asking about.