Conception problem

Conception problem

[Nicolas Gautier]

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.

Let us have instances of a class A. TO Each instance of A
 corresponds an instance of class B, which belongs to a list of instances
of objects
of class B(ListOfB). When an 
object A asks to his B to modify itself, the object B modify itself, but
this might have 
consequences on other objects of ListOfB. So, a change on an element of
ListOfB might 
triggers a change on an other element of ListOfB.
Here are two solution to solve the problem. I 'd like to have your opinion
about
which one should be used and why.
Thanks in advance.
 
solution 1 :
A has a reference of an instance of an object of class B. 
Each instance of class B has got data and a reference on the list of all
objects B 
(which is a variable known by all the instances of class B - static
variable in C++)
When A asks his B to modify itself, the object modify its data and then use
the 
static list to modify the others data of the list concerned by the
modification.
in C++, we would have something like:

class A {
B *TheRefOnMyB;

//implementation

*TheRefOnMyB -> modify();
}

class B{
static TheListOfAllB;

// implementation of Modify()
this -> ModifyMyself(); //modify this instance
Modify(TheListOfAllB); // modify the static list
//
}


solution 2:
A knows the structure ListofB that handles objects B  and has a key B_Key
on his
instance of B.
When A has to modify his instance of B, it asks the structure ListOfB to
modify the object
 with the key B_Key and to modify the other elements if they need to be
modified.
in C++, we would have something like :

class A {
ListOfB *TheListOfB;
BKeyType B_key; // Bref is a type defining a key on an object B, this key
is known only by
            // the object ListOfB
...
//implementation
TheListOfB -> Modify (B_Key);

//
}

class ListOfB {
...
//defintion of the list and of the type BKeyType
...
// implementation of modify(B_Key)
this -> ModifyTheElementWithTheKey(BKeyType);
this -> MOdifyTHeOtherElements();
//
}

Re: Conception problem

[John Heidelberger]

Nicolas Gautier wrote:
> 
> 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.
> 
> Let us have instances of a class A. TO Each instance of A
>  corresponds an instance of class B, which belongs to a list of instances
> of objects
> of class B(ListOfB). When an
> object A asks to his B to modify itself, the object B modify itself, but
> this might have
> consequences on other objects of ListOfB. So, a change on an element of
> ListOfB might
> triggers a change on an other element of ListOfB.
> Here are two solution to solve the problem. I 'd like to have your opinion
> about
> which one should be used and why.
> Thanks in advance.
> 
> solution 1 :
> A has a reference of an instance of an object of class B.
> Each instance of class B has got data and a reference on the list of all
> objects B
> (which is a variable known by all the instances of class B - static
> variable in C++)
> When A asks his B to modify itself, the object modify its data and then use
> the
> static list to modify the others data of the list concerned by the
> modification.
> in C++, we would have something like:
> 
> class A {
> B *TheRefOnMyB;
> 
> //implementation
> 
> *TheRefOnMyB -> modify();
> }
> 
> class B{
> static TheListOfAllB;
> 
> // implementation of Modify()
> this -> ModifyMyself(); //modify this instance
> Modify(TheListOfAllB); // modify the static list
> //
> }
> 
> solution 2:
> A knows the structure ListofB that handles objects B  and has a key B_Key
> on his
> instance of B.
> When A has to modify his instance of B, it asks the structure ListOfB to
> modify the object
>  with the key B_Key and to modify the other elements if they need to be
> modified.
> in C++, we would have something like :
> 
> class A {
> ListOfB *TheListOfB;
> BKeyType B_key; // Bref is a type defining a key on an object B, this key
> is known only by
>             // the object ListOfB
> ...
> //implementation
> TheListOfB -> Modify (B_Key);
> 
> //
> }
> 
> class ListOfB {
> ...
> //defintion of the list and of the type BKeyType
> ...
> // implementation of modify(B_Key)
> this -> ModifyTheElementWithTheKey(BKeyType);
> this -> MOdifyTHeOtherElements();
> //
> }

From an object modelling point of view I'm not sure there is enough
information to discuss the virtues of either approach.  What we are
examining here is not a business issue but an implementation issue.  

I guess one question I have is the size of the collection and "need for
speed."  It would seem that approach 1. has the advantage of being
quicker yet more complex for the code (i.e., adding and removing things
in the list of other objects on B).  In approach 2 you go and find all
those things that need to be updated and update them.  If you can write
an efficent search this might not be a bad appraoch.

The are some other factors to address.  Does the update to B update the
"key" elements?  If so does this result in mass
additions/deletions/re-organization to the collection of B's and
consequently the collections of realted B's.  It seems that what we are
really trying to do here is select an appropriate data structure.  You
need to take into account the operations that will need to be performed
on the data structure, the frequency of these operations, the
requirements in terms of performance for the operations, the amount of
complexity you are willing to deal with, the estimated size of the data
structure, etc.  All of these factors together will help you decide
which approach is best.  Good luck.

-- 
John Heidelberger
American Management Systems, Inc.
Object Technology Practice

Re: Conception problem

[Jim shaw]

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).


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.
> 


Ciao!
Jim Shaw

Re: Conception problem

[Russ McClelland]

> 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...

Re: Conception problem

[Malcolm Macgregor]

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 ...
Hey this a Smalltalk group don't bring your java terms in here:-) This
pattern in
Smalltalk is generally referred to as MVC. 
>> 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.
This is a standard MVC situation and the VisualWorks cookbook tells you how
to
do exactly  this sort of thing in very few lines of code.I'm sure IBM  and
express
will have the same sort of thing. Post again if you can't get hold of VW.
What 
language are you wanting to do these list sort of things in?

P.S. Definitely read Gamma, and I'm joking about use of Observer.
Observer-observed
is a more general term than MVC and should become part of Smalltalk lingua
franca.