Observer/Observable and update(Observable o, Object arg)

Thread view:

Jason Cavett - 19 Apr 2007 21:57 GMT

So, I am currently using Observer/Observable pattern in quite a few
spots in an application I'm designing. It works great and makes
designing the entire application fairly pain-free. There's just one
question I had about part of the system that seems a
little...clunky...

When my Observable object notifies the Observer object, there are many
ways the Observer object can react depending on what changed in the
Observable object. As such, I use...

observableObject.setChanged();
observableObject.notifyObservers(SOME_STATIC_FINAL_STRING_HERE);

The Observer object then implements update(Observable o, Object arg).
Currently, I am donig an if/else comparison against the arg object so
I know exactly what to update. This seems *somewhat* clunky, though,
because some of the Observers get quite a long list of if/else's in
their update method.

Is this the right way to go about it? Is there something better I
could be doing?

Thanks

Reply to this Message

Tom Hawtin - 19 Apr 2007 22:17 GMT

> So, I am currently using Observer/Observable pattern in quite a few
> spots in an application I'm designing. It works great and makes
> designing the entire application fairly pain-free. There's just one
> question I had about part of the system that seems a
> little...clunky...

The pattern is called "Observer". That doesn't mean you have to use the
interface named Observer. IMO, Observer and Observable should have been
deprecated in 1.1. The 1.1+ idiom is event listeners.

> When my Observable object notifies the Observer object, there are many
> ways the Observer object can react depending on what changed in the
> Observable object. As such, I use...

If you use event listener, you can have one observer (the listener) with
a number of methods.

However, using listeners that try to work out what has changed is going
to be a disaster. Swing is packed full of little bugs because of this
problem, and it also has lots of hacks to prevent the problem.

The best way is to assume everything that could have led to the event
did cause it. Duplicate no state. If there is a performance problem,
optimise but don't assume that the original state + event information
gives you the current state.

You could create a log of changes (as a database does). Then when a
listener receives an event, process the entire log since last update. I
have never seen this done.

Tom Hawtin

Reply to this Message

Stefan Ram - 19 Apr 2007 22:30 GMT

>Is this the right way to go about it?

»Models must be able to notify any interested parties
(such as views) when their data or value changes. Swing
models use the JavaBeans Event model for the
implementation of this notification. There are two
approaches for this notification used in Swing:

Send a lightweight notification

that the state has "changed" and require the
listener to respond by sending a query back to the
model to find out what has changed. The advantage
of this approach is that a single event instance
can be used for all notifications from a particular
model -- which is highly desirable when the
notifications tend to be high in frequency (such as
when a JScrollBar is dragged).

Send a stateful notification

that describes more precisely how the model has
changed. This alternative requires a new event
instance for each notification. It is desirable when
a generic notification doesn't provide the listener
with enough information to determine efficiently
what has changed by querying the model (such as
when a column of cells change value in a JTable).«

http://java.sun.com/products/jfc/tsc/articles/architecture/

Reply to this Message

Observer/Observable and update(Observable o, Object arg)

Free Magazines