Bus or listeners/delegates in client-side Swing application?

Question

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?

Answer 1

The convention in Java Swing is to use listeners heavily. Sticking with the convention improves maintainability but stifles innovation.

I've not encountered the bus approach in Swing, but I find it interesting.

Answer 2

Well, I can imagine the approach where models are updated using BUS like system and events from models are delegated using listeners. Simple scenario: I got server side which represents producer of data. Then on client side a got consumer interface which consumes all incoming messages and transform them into my internal messages/DTOs and push them into bus which distributes them into application model(s). These model process incoming messages and decide to notify interested components using listeners.

Answer 3

In my experience, trying to make Swing do something it wasn't designed for, or doesn't want you to do, is extremely painful.

I would go with the simplest thing that would work; keep your code clean, do it the "Swing Way" until you start seeing problems.

Answer 4

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.