Does anybody happen to have a link to discussion/implementation of observer pattern which ask observer to notify only if particular attribute regarding a subject has changed as against getting notified for all changes for that subject. Thanks
JMS does something like that. Subscribers subscribe to a topic and get messages on that topic only. I suppose you could use a hierarchical naming scheme for topics "user.preferences.screensize" to drive to any granularity you need. I made my own little "publisher" class that has a two-part key that works the same way. It's a little different from Observable in that it calls specific methods with any signature you please. I can provide more on that if you like. A couple resources: Enterprise Integration Patterns and my own Messaging Patterns touch on this kind of thing.
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: Nov 22, 2001
Thanks Stan. If it is OK with you, can you share info. about the implementation
When I've needed somthing like this I've tended to use an Observer-Observer or "filter" approach. Register an object with the event source which is both an event listener and an event source in its own right. Then register the "real" listener with the intermediate source. The intermediate source is then free to ignore, modify, or simply pass on events to its listener(s) as required. In a hypothetical framework example, this intermediate listener/source might look like:
If this seems too fiddly, you may want to look at a flexible, yet strongly-typed "event bus" such as the ReflectionBus from werx. Originally designed as a way of wiring together Swing applications, it has now been extracted as a usable component on its own - and the standalone "bus.jar" is only 16k!
Sure, this will get a bit long tho ... I did this in like my second week in Java ... be gentle if it shows.
And the Package docs:
Provides the Publisher framework for pub-sub or listener patterns. Publishers may be public so subscribers may subscribe directly, or composed into event-generating classes behind familiar addListener() and removeListener() methods. Extend the abstract Publisher class to create actual publishers. The abstract Publisher class provides framework services to track subscribers. It keeps them in static variables so the subscriber list survives repeated creation and GC. [Why are all methods not static? I don't remember!] When you call a method on a publisher, the publisher forwards the call to all subscribers. The publisher author has to write this code, but it is largely cut and paste from the samples below. Methods can use any Java parameters, return types, etc. Publishers identify events by a two part ID: Name + Key. Subscribers find valid values in publisher documentation and subscribe accordingly. Typical usage would be publisher name plus event name. For example, the Scheduler always uses a Name of "ScheduledEvent". The key is the the event type, so a subscriber may select which events it wants to receive. In this version name and key must find exact matches. In future versions it would be interesting to allow regular expression matching. To write a publisher: * Write Interface IMyEvents with myMethod. Name the interface and methods so they will make sense to subscribers, not to publishers. * Write class MyPublisher that extends Publisher and implements IMyEvents * In MyPublisher method(s) required by IMyEvents, iterate all subscribers and call the same method with the same parameters on each.
To write a subscriber: * Write class MySubscriber that implements IMyEvents * In MySubscriber call MyPublisher.subscribe( "name", "key", this ) * In MySubscriber methods defined by IMyEvents, handle incoming events Sample subscriber class:
Any class can publish a message to all subscribers
This is a bit unlike most publish-subscribe or observer implementations. * The interface IMyEvents can define any number of methods. You can use the same publisher to fire off a number of different events. * Publishers may be destroyed and recreated while subscribers hold their subscriptions. E.g. a model that publishes data changed events may be created and destroyed repeatedly without affecting the subscribers. * Multiple applications may publish the same events, and all publishers get all the events. E.g. several panels might publish the same data changed event. * Methods may return values; the publisher may then aggregate or summarize the returns from all the subscribers into one result. One might use this for voting or polling. A publisher might call subscribers until one returns a value that indicates the subscriber has "consumed" the event and not call any more subscribers.
Joined: Nov 22, 2001
Thanks to both of you Frank & Stan (in alphabetical order)