comp.lang.ada
 help / color / mirror / Atom feed
From: John Heidelberger <john_heidelberger@mail.amsinc.com>
Subject: Re: Conception problem
Date: 1997/05/29
Date: 1997-05-29T00:00:00+00:00	[thread overview]
Message-ID: <338D9DF5.4F4E@mail.amsinc.com> (raw)
In-Reply-To: 01bc6b91$54b26a60$d19ecec2@beta


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




  reply	other threads:[~1997-05-29  0:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-05-28  0:00 Conception problem Nicolas Gautier
1997-05-29  0:00 ` John Heidelberger [this message]
1997-05-30  0:00 ` Jim shaw
1997-05-30  0:00   ` Russ McClelland
1997-06-03  0:00   ` Malcolm Macgregor
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox