Re: Design of cross referring types/classes and proper usage of containers

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 3 Aug 2015 09:08:15 -0700 (PDT), Serge Robyns wrote:

> I've a design issue with regards to what is the best if not ideal approach
> in building types or classes that refer to each other and could be
> aggregates.
> 
> Lets use an example  I've the following entity:
> 
>    type T_Client is tagged record  -- will be mapped a table
>       Id         : Integer := 0;
>       First_Name : T_Client_Name := T_Client_Name (P_Empty_String);
>       Last_Name  : T_Client_Name := T_Client_Name (P_Empty_String);
>    end record;
> 
> This is to keep track of client info.
> 
> I've the following other entity amongst others.
> 
>    type T_Subscription is tagged record  -- will be mapped to a table
>       Name    : T_Subscriptiont_Name := No_Subscription_Name;
>       Product : T_Product_Name := No_Product_Name;
>       Client  : T_Client := No_Client;   -- Could also be of the same type T_Client.Id, used in different approach.
>       Date    : Ada.Calendar.Time := GNAT.Calendar.No_Time;
>    end record;
> 
> And I've other entities as well that do have similar relationships.

When aggregation does not work, which is the case when relationships are
complex, you keep them outside. You create maps

   Client to [not null access] Subscription
   Subscription to [not null access] Client

etc. And search the maps if you have one and need another. For the map you
can use hash or binary searched container.

Note that aggregation is fragile. If you have a suspicion that
relationships may go chaotic, don't aggregate.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de