This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I was reading Agile Software Development and there was a bit on the observer pattern. For this bit he was discussing C++, but I wasn't paying much attention to that fact. He had made the "subject" an abstract class. I thought this was rather odd in that I would normally make this an interface. However, after I thought about it, an abstract class would have all the notification methods built right in so any users would not have to reimplement all the notificaiton methods. Plus, you can use multiple inheritance in C++, so you don't end up with the identity problem.
Is there any similar technique in java that would allow me to capture all the notification methods in a single class? Delegation seems a likely choice and IIRC true delegation would not have the identity problem.
Just wondering if others are using a technique here, or reimplementing notification methods in each new observable they create.
java.util.Observable, one of the oldest classes in the Java API, is an implementation of exactly this. I've used it occasionally, and I've also used PropertyChangeSupport, and also used hand-coded notification. Observable's API and behavior are a bit odd, just different enough from what I expect that I generally find it uncomfortable to use.
I tend not to use Observables. Instead I build a separate publisher. GoF has an intermediary like this as an option in the pattern. It gets all the event publishing stuff out of the observed object.
My publisher and listener implement the same interface which can have any number of context specific methods, what Don called strongly typed events I think. The publisher forwards method calls to the subscribed listeners. I have to hand-code all the publishers but they are trivial. Subscription features come from an abstract base class.
This is subtly different from Observer. Any number of event source objects can publish the same event while listeners subscribe just once. I can create and destroy event sources over time without disturbing the subscriber list. And the hand-coded publisher can poll or take votes from listeners, aggregate return values from listeners, stop after the first listener "consumes" the event, and other interesting variations.
Any of that sound useful?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Dec 12, 2002
so when you subscribe to a topic you recieve events from all publishers on that topic right? As opposed to Observer where you listen to events from a particular publisher.
Joined: Jan 29, 2003
Right. That's either good or bad but it's different for sure. Actually it's a lot like using one observer for a bunch of buttons and testing for some field on the message (which might include the sender) to decide what to do. It can work.
I use it for one program that has to match sender & receiver and I put an id into the subscription topic, which has a two-part key.
For now the subscriber list is "global" in a static map of maps. That could surely get into topic namespace trouble in a large system.
Here's a concrete publisher example. The topic really only has one part, so I use a "*" for the second part to document "all."