observer vs listener vs my own mix

[antoine]

Hello,

after having developped several graphical applications "that just work"
(dirty code), I've decided to clean the code a bit, especially to
separate business logic from graphic elements.

one thing I've started to use heavily is "some kind" of observer /
listener pattern to link data displayed in components to data hold in
logical structures.

for that, I actually don't really understand the difference between the
Observers and Listeners. to me it appears that Events listened for by
Listeners are fired on the Event Dispatching Thread, while using
Observers implies I stay on the same thread. first, am I correct to say
such thing ?

on my end, I've implemented a mix of both methods, by creating
interfaces that I could call "myObjectListener", that will define only
one method: update(int source), and several public constants int
describing the possible sources.

I also define a notifyListeners(int source) and a
addListener(myObjectListener l) in my BIG "business" element. listeners
hold in a vector, and I use Iterator... (even though I have only ONE
listener most of the time).

in doing so, when element A changes in my BIG "business" element, I
simply call a notifyListeners(source_A), that does a callback on all my
listeners, calling for the "graphic" update of element A ONLY.

question is simple: is that clean code ? what's wrong with all that ?

I mean, it's working OK, I might be paranoid, but I'm pretty sure
there's an argument against this method, so that's why I'm asking the
experts of this group
wouldn't there be a way to do this that would make more sense ? how can
this compare to the Listeners / Observers patterns ?

thanks for your feedback, hope I've been clear enough...

-Antoine

 

[Ed]

antoine skrev:

-snip-

for that, I actually don't really understand the difference between the
Observers and Listeners. to me it appears that Events listened for by
Listeners are fired on the Event Dispatching Thread, while using
Observers implies I stay on the same thread. first, am I correct to say
such thing ?

I don't know for sure, but to me the Swing Event/Listener mechanism is
just an implementation of the general GOF Observer pattern; yes, in
Swing Events are sent in the event dispatching thread, but that's not a
rule of the general design pattern.

on my end, I've implemented a mix of both methods, by creating
interfaces that I could call "myObjectListener", that will define only
one method: update(int source), and several public constants int
describing the possible sources.

I'm not sure how this is a mix of the two cases you cite above, i.e.,
the general case and the specific Swing implementation. What you define
here and below sounds like a normal Observer pattern to me.

I also define a notifyListeners(int source) and a
addListener(myObjectListener l) in my BIG "business" element. listeners
hold in a vector, and I use Iterator... (even though I have only ONE
listener most of the time).

in doing so, when element A changes in my BIG "business" element, I
simply call a notifyListeners(source_A), that does a callback on all my
listeners, calling for the "graphic" update of element A ONLY.

question is simple: is that clean code ? what's wrong with all that ?

Did you check GOF for when the Observer pattern should be used and when
it's overkill? I don't see anything specifically, "Wrong," with your
approach that isn't, "Wrong," with the general design pattern.
Essentially, if it's crucial for you to decouple your model from your
view, then Observer is a fine way to go; the cost is basically the
added complexity. It may be note-worthy that you mention later that you
usually only have one listener; but even with no plans to expand the
number of listeners in future, you may judge the encapsulation which
the pattern affords you to be still worthwhile.

Perhaps it might be useful to show an example of where Observer was
overkill (in my opinion) and the alternative (stronger coupling between
model and view) was more attractive - see:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs100.html

..ed