Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Observer pattern in Java vs. C++

 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find that all my observable objects fire different strongly typed events.

There is a mechanism for standard attribute change events (java.beans.PropertyChangeSupport) that you can use by delegation.

D.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Java UI stuff tends to use a similar approach, except that there are usually two things created, and interface to define the methods, and an "Adapter" class to provide default implementations.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But that adapter is for the observer. What I am talking about here is an abstract class for the oservable or "subject."
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ulf Dittmer
Rancher
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a hands-on tutorial on event delivery techniques over on IBM DeveloperWorks, which shows various way to do this in action, amongst them the ones mentioned above.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
re: Stan

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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic