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

[Serge Robyns <serge.robyns@gmail.com>]

On Monday, 3 August 2015 18:08:17 UTC+2, 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.
> 
> The application is keeping parts of the (static) data in memory but eventually all the data will be retrieved and stored into a database.  I'm planning to use a design pattern (bridge or others) to implemnent this step.
> 
> However, I'm wondering what would be the best Ada approach to have these objects interacting, i.e, referring to each other.  Currently I'm using the db approach, which means I use keys to search in various independant containers.
> 
> But why not for example, Client that could have an Ada container of T_Subscriptions.  This container could be either the object itself or a reference (access) or why not a Cursor to another Container containing all subscriptions.  The same applies for the client in the subscription.
> 
> And I've a few other of such entities/cases.
> 
> I'm all ears to the audience experience in this matter.
> 
> Regards,
> Serge

And I forgot to mention, I'm trying to avoid access as much as possible, where it makes sense.  In my C-days, I would have independant containers and use references/pointers.