I’m aware of the support classes. It’s still a lot of buggering around for what really should be a simple thing. Perhaps what we really need here is better language support for this idiom. Not sure what form that would take however.

the infrastructure required to deal with adding and removing listeners, firing off events, creating interfaces put me off

Java does provide the java.util.Observable class and java.util.Observer interface. Too bad Java doesn’t believe in multiple inheritance, though. Or at least, if Observable had implemented an interface that your class could implement by delegation.

Of course, if you have multiple events that might want to be observed independently, then you need multiple Observable objects and inheritance wouldn’t do the job anyway. Then the simplest approach is for the observer to request the appropriate Observable from your object, and register itself with the Observable. A nicer approach is for you to create event-specific add/delete methods in your object that simply delegate to the appropriate Observables.

Doug brings up some pretty good points too.

An object’s instantiator may not be the thing that uses it, and passing dependencies into a constructor isn’t really adding complexity, just making the complexity that is already present in the system more explicit.

But the use of some tecnniques to instantiate the object (I’m thinking Spring and Pico here) can often obsure how the dependencies are being created and passed in in the first place. I’m not saying that this is a reason not to use Spring or Pico, but that when using them in a system (especially an existing system) you can end up muddying the water somewhat.

I tend to think of ‘construction time’ and ‘use time’ of an object as distinct and separate. An object’s instantiator may not be the thing that uses it, and passing dependencies into a constructor isn’t really adding complexity, just making the complexity that is already present in the system more explicit.

An example from (painful) personal experience: an object was iterating through a list and found something it didn’t like. It notified its listeners, one of whom tracked down the offending list item and removed it from the list. After the listeners returned, the original object attempted to continue using the iterator, with unpleasant results. (In Java it would be a ConcurrentModificationException).

This is where the danger is: the listener interface being used had no contracts which said what the listener was (and more importantly, wasn’t) allowed to do. The listener went off doing something that seemed to be perfectly reasonable and quite helpful: eliminating the trouble-making situation. However, the original object was in a state which could not tolerate that particular kind of help.

Not a problem in Java, but I’ve seen an extreme example in C : one of the listeners made a “fixup” that indirectly resulted in the original object being deleted. When the listeners returned, hilarity ensued.

Certainly the Observer pattern CAN be used without problems; people have been doing so for an awful long time. But there are hazards that must be considered, and having no contracts on the Listener and then using a Controller as a Listener definitely increases the “threat level.”