Event Listeners and GOTOs?
A couple years ago I was given the impression that in the future all good software design would be based on event/listener patterns. This was especially true in Java, as I understood things. I've discovered in the process of trying to realize that goal is that I often follow my code to the point where events get fired, and start grepping the source tree for the code that listens for these events.
Often (usually) I can create the same functionallity with 'deterministic' code that explicitly names the recipiant of the message. It seems to me that event/listener design has the same potential pitfalls as the dreaded and accursed GOTO from years gone by.
I will add that the variety of event/listener implementations in Java also presents a problem. It is usually not clear how I am expected to use a particular type of Event object, and the various implementations seem to diverge drastically. For example the ChangeEvent and ActionEvent classes seem to be based on significantly distinct philosophies.Most of the sample code I've seen using these various events reminds me of bailing wire and duck(sic) tape. That is, the programmer seems to have improvised a means of employing the Event object available rather than using a feature inherent to the API.
As an aside, I know part of the awkwardness of has to do with issues of generic programming, and the need to re-cast objects once they are recieved in event notifications. After speinding about a month on C++ templates I realized there are potentially worse things in life than the need to explicitly cast an Object here and there.
I would like to hear people's thoughts regarding down-sides of event/listener patterns. Before I bagan typing this message I tried to look at what the Gang of Four had to say about this in the _Design Patterns_ book. To my surprise, they had very little to say.
[1891 byte] By [
hattonsa] at [2007-9-29 19:51:23]
> I would like to hear people's thoughts regarding
> down-sides of event/listener patterns. Before I bagan
> typing this message I tried to look at what the Gang
> of Four had to say about this in the _Design Patterns_
> book. To my surprise, they had very little to say.
The GoF do mention the Observer/Observable pattern though, which is functionally equivalent to the
Listener pattern ...
kind regards,
Jos
Part of the point of the Event/Listener pattern is to decouple the event source from the event handler.
Explicitly naming the event handlers can lead to very tightly coupled code (which can get complex real quick)
This is one of the decisions you need to make when choosing an appropriate pattern.
Other factors (from the GoF)
The event source will not know the cost of sending the event. As there can be an arbitraty number of
listeners which in themselves can have their own listeners your Event source cannot know how much
work is needed to be done. In addition you will probably need a more complex protocol to specify
regions of change such that the listeners don't have to work too hard to figure out wht has changed
for themselves.
The weak coupling between the source and listener can cause maintanance problems.
The pattern requires very good documentation of the dependencies between sources and listeners to
ensure that chains don't get to long and don't cause loops.
Its just a shame that many people have not bothered to learn about the pattern before using it to solve every
problem under the sun. The awt/swing API's make fairly good use of it as they have a strong requirement
for sources and liteners to be decoupled from each other.
matfud
Your observations are fully consistent with my own. I will add that, in Java there are, ostensibly, means of labeling events so loops can be terminated. I haven't gotten that deep into Swing/AWT development to understand how they are used. I have used that type of feature in DOM related JavaScript code.
One aspect of Java's event/listener implementation I find confusing is the (apparent) lack of documentation describing the event sources. That is, it's not hard to see who will listen for what, but trying to figure out the type and nature of events generated by an object is a different story. Classes are clearly specified as implementing event listener interfaces, but they don't have corresponding event producer interfaces.
I cannot easily look at the API documentation of, for example, JTable, and easily determine what kind of events it will produce, and what properties the event objects will possess. It is also not clear what I am expected to do with the event properties.
This may be a topic better suited for the Swing forum, but since I started here, I will keep it here for now.
There are a few implementations of the listener style pattern in java.
The java.util.Observer/Observable is one such. In this case it is up to the Observable derivative to
document the type of changes it notify you of. This implementation is strange as the Observable is not
an interface (nor does it implement one) but rather a class you need to extend.
Swing and AWT also do not use interfaces to specify the capabilities of their producers. Admittidly, in many
cases, the use of an interface provides no benifit as teh types of event generated are very specific. However
there are cases in which specifiying the capabilities of the Source via interfaces would be benificial.
Swing does however follow a naming convention for registering Listeners (addWhateverListener). Then
the specifics of the listener are defined in the WhateverEvent class. Variations from the info found in the
WhateverEvent class should be documented in the source that creates those Events.
Its not as bad as it seems at first sight. Whether you prefer the use of interfaces or naming coventions both
work well (usually in different situations).
If you are not carfull using interfaces to specify producers/sources then you can end up with double the
number of classes you might need for the approach based on naming conventions. Many of these
interfaces will have little shared use.
matfud
matfud
If I may throw in my 2c worth...
I agree that the producers of events are generally very poorly documented. I have struggled several times to work out which event I need to listen for with the Swing GUI in particular - they are not entirely consistent across source classes either which doesn't help.
Additionally, the complexity produced by layering listeners on top of listeners (especially with third party components built on top of Swing), coupled with the fact one often doesn't have control over the order they are called in, makes it nigh impossible to follow what is going on. I've nearly torn my hair out (and still might!) over the GUI components I am trying to use in my most recent work project.It almost always ends up with at least one of the listeners firing the event again so all the handlers seem to get called two or more times for each originating event - not exactly efficient and enormously confusing to understand and debug, particularly as the data is sometimes manipulated and transformed by the earlier listener calls so a different path is followed through the same code on subsequent invocations.
Certainly I originally (perhaps naively) thought the observer/observable pattern was wonderful and would remove all coupling, and all applications would work that way with no further requirement to talk directly between components. But surprisingly in the real world it turns out (at least for me) to be far from the most understandable/debuggable way to work. In the end I have tried to restrict my use of listeners to a few distinct patterns such as views of data (i.e MVC); and instead directly access public methods elsewhere.
I think it is one of those classic examples of a technique that solves some problems (e.g. MVC) very well, but can easily be overused in other situations.
Regards,
Tim
