• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Observer pattern in Java vs. C++

 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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."
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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."
 
reply
    Bookmark Topic Watch Topic
  • New Topic