[Gambas-user] 38 different classes - all exactly the same.

[Benoît Minisini]

Le 04/09/2012 08:13, Bruce a écrit :
> As usual this is hard to explain in a short message, but here goes.
>
> We have a major library that provides all the persistence mechanisms for
> what we call "Business Objects".  In our case it's Horses, Stables,
> Auctions, Trainers, Owners, etc etc, currently 38 of them and growing.
> The reason for this is that the database design changes incrementally on
> a frequent basis when one of the clients comes up with another good
> idea. With 166 different applications to support, it makes sense to cope
> with data changes in one central library.
>
> I have been trying to abstract a lot of the methods in the library
> classes and have got to the point where the majority of the common logic
> is contained in two major classes, and its all driven by metadata "maps"
> that relate the BO attributes to the relevant columns and tables in the
> database (and vice versa).
>
> The roadblock I have now struck is this.  Each BO class requires a
> special "partner class" that contains the metadata as a static
> attribute. Each of these classes now looks exactly the same, same data
> items, same code.  The only difference is the class name.  Thus, 38
> different classes - all exactly the same.  But at runtime, obviously,
> each has a different metadata map loaded.
>
> What I'd like to be able to do is have only one of these, rather than
> 38.
>
> The reason that the metadata is held as a static attribute is that
> during any execution of a given program, there might be hundreds
> (sometimes thousands) of, say, Horse objects created.  So it makes sense
> to only load the metadata once and share it amongst all the BO's of that
> type.
>
> So, is there some way to create a class i.e. a new class not a new
> object, based on that common code at runtime?
>
> I have attached a picture that I hope might help in understanding where
> I'm coming from.  It's the brown classes inside the pinkish box.
>
> I've tried looking at design patterns for something like this but really
> can't find anything that seems to match.
>
> regards
> Bruce
>

I don't understand everything, so maybe I will tell rubbish: if all 
these classes share the same code, why not using inheritance?

-- 
Benoît Minisini