Implementing the Observer Pattern in a Chain

  • Thread starter Thread starter Charles Law
  • Start date Start date
C

Charles Law

I have the following hierarchy

ClassA
contains ClassBCollection
which contains ClassB objects
contains ClassCCollection
which contains ClassC objects

I am using the observer pattern, so in ClassC I have an event Notify, and a
method OnNotify that raises this event. This event must be passed all the
way back up the chain to ClassA.

It is tedious and error prone when I want to add a new event, because I have
to insert AddHandler and RemoveHandler calls at various levels, sink the
event at other levels, and create OnEvent methods all over the place.

Is there a convenient way of automating this, or is there a simpler way to
implement the pattern?

I also encounter the situation where my event sink wants to call
OnNotify(sender, e) in the middle of the chain, but I also want to call
OnNotify(message) as well. I could create two methods, but the pattern does
not seem to imply the need for this. Am I missing something? It's all
getting mighty complicated.

TIA

Charles
 
I have found using interfaces cuts down on the complexity. Also I would
refactor your class. Is it really necessary to have that degree of depth in
your classes?

Public Interface ILoadStatus_Notifier
Sub RegisterLoadStatusObserver(ByVal o As ILoadStatus_Observer)
Sub UnRegisterLoadStatusObserver(ByVal o As ILoadStatus_Observer)
End Interface

Public Interface ILoadStatus_Observer
Sub NotifiyLoadStatusObserver()

End Interface

I also find its easier to bubble events than notifications. Sometimes I have
found myself trying to use a notifier-observer when a simple event would
have sufficed. Observer patterns really should be used when a single class
has to notify several other objects of a change to its state(or at least
thats the best use I have found for it so far). For instance I have a
control that monitors the status of several dock doors. When a user clicks
on a door it opens a form, I use an Observer pattern to send the pertinent
information to the various controls on the form that need to know
information(loadnumber, docknumber, status). But the key is I have a
controller-mediator object between the indicator and the actual controls it
sends to. the mediator is the notifier(it catches an event from the
indicator) it then notifies the controls of the statechange.
 
Is it really necessary to have that degree of depth in your classes?

The hierarchy represents a DOM, so in fact it could be nested even more
deeply because a section in a document can contain sections, which each
contain sections, and so on.
I also find its easier to bubble events than notifications.
Click to expand...

I'm not sure I understand the distinction. I am using Microsoft's Event
pattern to implement the observer pattern. Am I bubbling events or
notifications? When a particular event occurs I call OnNotify to raise the
event to the observer. At the paragraph level, this is caught by the section
level, which then bubbles it to the parent section, and so on up the chain
until it reaches the document level.

Charles
 
unfortunately then you are implementing the pattern in a way with which I am
not familiar. If you are not notifying multiple items of a statechange in
one object then IMHO you are overkilling with an observer pattern.

In your case I would simply bubble events.

Public Event StateChangeX

StateChanged
RaiseEvent StateChangeX



Parent Class
Public Event AnotherEvent

addhandler childClass.StateChangeX, address of ChildClassStateChanged

ChildClassStateChanged
Raise AnotherEvent
 
I'm prepared to learn that I have implemented it incorrectly. My top level
document object has an Advise method, to which is passed the observer so
that the handlers can be hooked up.

I think that what I have is both scenarios. The DOM bubbles events using the
event pattern, and when the event gets to the top level the observer is
notified, a la the observer pattern.

On this basis, it is the bubbling that is the headache. Adding a new event
that gets bubbled all the way to the top means modification to all classes
and collections in the DOM in many different ways. This is the bit that is
error prone because there are upward of eight or nine places to add code to
make the link.

You can probably guess that I have just added another event and it took me
over an hour to do because I couldn't find the place where I had omitted to
add the correct linking code.

Charles
 
do this....maybe...

I would make a controller class. This controller would sit outside the DOM
object and would then feed the state to the various classes as needed. Its
more of a bypass than a bubble.


xClass raises event that is caught by controller. Controller notifies
observers that event was raised.

Make sense? The observer Pattern is more complex than it appears at first
looks. Implementing it properly takes some planning.
 
Back
Top