[ruby-talk:8184] Thoughts on the observer mix-in [long] (was: Re: Method as block to method)

> > I find myself wanting to pass a method as the block to
> another method on a
> > fairly regular basis, and I don't really like how the code
> turns out.
> > Currently it looks like this:
> >
> > 	result.addFaultListener(self, &(method(:addFault).to_proc))
>
> Rather than adding a method, why not add an observer class?

Well, when I first implemented my observable/observer, I had forgotten about
the Observable mixin, so I started from square one, trying to figure out the
simplest and most useful implementation of observer for my needs. What I
came up with (and have used several times now) is something like this (note
that I have not run this example code):

	class ObservableThing
		def initialize
			@thingListeners = Hash.new
		end
		def addThingListener(key, &proc)
			@thingListeners[key] = proc
		end
		def removeThingListener(key)
			@thingListeners.delete(key)
		end
		def notifyThing(thing)
			@thingListeners.each {
				| key, proc |
				proc.call(thing)
			}
		end
	end

	class ThingObserver
		def hookUpTo(observableThing)
			observableThing.addThingListener(self) {
				| thing |
				puts("Notified: #thing")
			}
		end
	end

	observableThing = ObservableThing.new
	thingObserver = ThingObserver.new

	thingObserver.hookUpTo(observableThing)
	observableThing.notifyThing("Wild thang") => Notified: Wild thang

My original question stemmed from the fact that often (but not always),
because of the way my code is factored, the most convenient proc to hook up
is a method on the observing class, i.e.:

	def hookUpTo(observableThing)
		observableThing.addThingListener(self, &method(:thingHappened))
	end
	def thingHappened(thing)
		puts("Notified: #thing)
	end

I like leaving it up to the observing class to choose what's the simplest in
his situation.

So, anyhow, I came up with this solution, and then everyone reminded me
about the observer, so I went to look at it. No offense to the original
author, but I really don't like it. Here's a run down of my thoughts on it:

Pros:
	Easy to mixin
	One method to implement on observer, none on observable (just call changed
and notify_observers)

Cons:
	Observable cannot have multiple 'thing' notifications
	Observer must either only listen to one observable, or he must multicast
the notifications himself
	Observable must often pass himself in the notification so that his
observers can multicast
	Observer must implement the update method

I guess it comes down to where I think the responsibilities for notification
should lie. To me, the observer has almost no responsibilities, other than
hooking himself up (and even that could easily be done by someone else, thus
completely encapsulating the observer from the observable). He should also
have as much flexibility as possible in how he responds to the notification.

OTOH, the observable is responsible for the tracking of observers and for
notifying those observers when something changes. He should _not_ dictate to
his observers how they implement their response to his notification, other
than (maybe) requiring that they accept a certain set of data.

Here are what I see as pros and cons to the approach that I've taken:

Pros:
	Easy many-to-many observer to observable correspondance
	Light, flexible observers

Cons:
	Not an easy mixin
	More code to add for each observable thing

I think that a mixin might be possible, negating both cons above, but I
haven't had time to delve into it yet. My initial thoughts are something
along the lines of:

class ObservableThing
	include Observable
	observable("thing")
end

which would create code equivalent to my ObservableThing class above. I'm
thinking some additional options might be useful, such as a number
indicating the number of arguments that will be passed to observers.

I'm curious to hear everyone else's thoughts on the pros and cons of both
the original observer scheme and my new scheme.


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|