Re: Idiom for a class and an object in Ada

[Michael Paus <pausnospam@nospamib-paus.com>]

Hi Marin,

your question has triggered an interesting discussion which I found
very amusing. Before I provide my proposal for a solution of your
problem I think it is essential to first discuss what the potential
benefits of your OO approach are.

You have chosen to use a tagged type to represent your A/D converters
which I think is a wise decision but neither you nor anybody else
seems to be able to give a good reason for that (if I have not missed it :-)
and also in the way you have started you are missing an opportunity
for flexibility in your design and for really exploiting your OO approach.

First of all your A/D converter class should be abstract and in all places
where you later access an A/D converter you should only refer to this abstract
base class. This gives you the possibility to easily exchange the implementation
of your A/D converter by providing different implementations of sub-classes of
your base class. The decision of which implementation you want to use can
even be done at run-time if you like. E.g., I often use this technique to
provide one sub-class for the real hardware and one which is only linked to
a simulation device which is connected via ethernet. I think this makes the
potential benefit of the OO approach clear.

Now that the goal is clearer it is easier to find a solution for your original
question. I like to be able to put together different configurations of my
software. E.g., one that is configured to run on the target and another one
which is used for a PC based simulation of the software and I want to change
as little of the software as necessary to create a new configuration.

I therefore have a
configuration specific main program and also a configuration specific package
which only has an "Initialize" and a "Start" procedure. As this package is
configuration specific no other package is allowed to access this package.
In this package I declare all the top level and configuration specific
objects statically and if some object needs another object I pass in a
class wide access value to the corresponding object in the "Initialize"
method. Alternatively you can also provide abstract factory packages for
these objects. This is useful in cases where an instance of these objects
is used in many places of your software.

 From a reusability point of view it is important that you keep the creation
of instances separate from the objects which use them. For me this approach
has worked very well and it even has some more advantages which I have not
discussed here.

Yours

Michael