From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,fb2e75ca89362493
X-Google-Attributes: gidfac41,public
X-Google-Thread: 109fba,fb2e75ca89362493
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,fb2e75ca89362493
X-Google-Attributes: gid103376,public
X-Google-Thread: 114809,fb2e75ca89362493
X-Google-Attributes: gid114809,public
From: "Russ McClelland" <russmc@netbox.com>
Subject: Re: Conception problem
Date: 1997/05/30
Message-ID: <01bc6d0b$c8551be0$3c04109b@russ-mc-760ed>#1/1
X-Deja-AN: 245003219
References: <01bc6b91$54b26a60$d19ecec2@beta>
 <01bc6c26$4e1c0ef0$ab526478@jims_nt_1>
Organization: Perot Systems
Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Date: 1997-05-30T00:00:00+00:00
List-Id: <comp.lang.ada>


> Nicolas Gautier <GautierN@sofreavia.fr> wrote in article
> <01bc6b91$54b26a60$d19ecec2@beta>...
> > Hello,
> > Sorry if this mail is a little bit long. This is a question about what
is
> > the best 
> > way to handle lists where modifications of one element can trigger
> > modifications
> > on other elements of the list.
> > 

> Jim shaw <James_P_Shaw@msn.com> wrote in article
<01bc6c26$4e1c0ef0$ab526478@jims_nt_1>...
> A better solution would be to implement the Observer design pattern
(Design
> Patterns, by Gamma et.al.). Just a quick blurb on this pattern (please
see
> book for more detail):
> 
> Essentially all objects of class type B, would keep a list of
"subscribed"
> objects to notify when an event of interest occurs. When a particular
event
> (of your own choosing) occurs, the object simply "notifies" all
subscribed
> objects of this event (i.e. send a message to that object).

As a refinement, I would have the class only hold a collection of
dependents.  The class generates the event and lets each dependent decide
whether or not they are interested in the dependent.  This helps separate
the class from the dependents and puts the decision in the observers.

If you are using VW, this is already available.  The "event" isn't really
an event object but pieces of information that are passed to the observers
like the aspect that changed, the new value etc.  One could probably extend
this easily to support real event classes.

Another idea would be to have the observer register as a dependent of the
specific event classes.  Whenever the event class created a new instance,
it would notify all the registered observers.

The difference between the two strategies is this:

S1.  The observers are interested in changes only to a specific instance.
S2.  The observers are interested in events at a system level, regardless
of a specific instance.


-- 
Persistence is futile.
You will be aggregated...