Classes and packages - recommended practice

Classes and packages - recommended practice

[Maciej Sobczak]

Hi,

Let's take the basic example with three types:

- Shape  (abstract)
- Triangle
- Rectangle

I have learnt three options to represent them as packages.
Let's choose the Objects/Object naming convention for the package and 
the actual type - this is the first convention presented in:

http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#Class_names


1. Make a separate package for each class.

This means that there are 6 files (3x ads + 3x adb). None of the 
packages is a child or nested withing another.

The client code may do the following to be able to use all names without 
qualification:

with Shapes;
use Shapes;
with Triangles;
use Triangles;
with Rectangles;
use Rectangles;

2. Make a root package Shapes and have the leaf classes in child packages.

This means that there are still 6 files.

The client code may do this:

with Shapes;
use Shapes;
with Shapes.Triangles;
use Shapes.Triangles;
with Shapes.Rectangles;
use Shapes.Rectangles;

3. Make a single package Shapes and have two *nested* packages for 
Triangles and Rectangles.

This means that there are only two files (shapes.ads and shapes.adb).

The client code may do this:

with Shapes;
use Shapes;
use Shapes.Triangles;
use Shapes.Rectangles;


My question is - when do you use which form?
The third options seems nice because it is compact. Not only there are 
just two files to mess with, but the "locality of reference" (in the 
sense of reading the source code) is higher when the whole hierarchy can 
be viewed in a single place. The problem is that this seems to be 
applicable only to closed hierarchies, when no new classes are likely to 
be added. Still, there are cases when that's exactly the case (for 
example, when the set of derived classes completely partition the 
superclass).
Second option (with child packages) seems interesting, because it is 
open for extension (no need to edit existing files when adding new 
sibling classes), and at the same time the relations between classes are 
expressed in package names (and file names) as well, which can ease 
navigation in the project.
First option is, well, ... so what would you say about the first option?

What do you recommend and when? Are the issues above the only ones that 
can be taken into account?

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Classes and packages - recommended practice

[Georg Bauhaus]

Maciej Sobczak wrote:
> with Shapes;
> use Shapes;
[lots more]

> My question is - when do you use which form?

I'll rarely use all types from all packages in the same place when
possible, because I want to leave that to the dispatching mechanism. :-)
So this is not the most frequent case.
That aside, I'm fond of plural/singular because of locality
of reference: "Object" doesn't say much compared to "Triangle",
and forces some form of qualification if you don't want to bother
your readers with doing the lookup themselves.

OTOH, in Ada 2005, we won't need so many "use"s
because of distinguished receiver notation...

-- Georg 

Re: Classes and packages - recommended practice

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message
news:439dc83c$0$27888$9b4e6d93@newsread4.arcor-online.net...
> Maciej Sobczak wrote:
> > with Shapes;
> > use Shapes;
> [lots more]
>
> > My question is - when do you use which form?
>
> I'll rarely use all types from all packages in the same place when
> possible, because I want to leave that to the dispatching mechanism. :-)
> So this is not the most frequent case.

Right. In fact, it should never happen (because it creates a point where
maintenance is a problem; you won't get an error if you omit one of the
classes), unless you have very few classes.

Generally, you only use the root type (for dispatching) and a couple of the
leaf classes.

Anyway, to answer your original question, I generally use a flat set of
packages (because it is less likely to have unintentionally dependencies).
But there is one important exception: if the child classes need access to
details of the root classes implementation. In that case, the interesting
stuff gets put into the private part of the root class, and the child
packages can see it, but none of the clients can see it and mess up the
abstraction with inappropriate operations.

That is, I choose the flattest structure that is consistent with what needs
to be hidden from the clients.

                   Randy.

Re: Classes and packages - recommended practice

[Martin Krischik]

Maciej Sobczak wrote:

> My question is - when do you use which form?

Often use the 2nd form - but without the "use" - I rather use "use type".
However all forms have there place in live.

#1 Any class which originates from Ada.Some_Package. You can't add new
packages to Ada.

#2 When you need access to the private section of the class. i.E type X is
tagged private;

#3 When there are a few small classes with tight coupling. You can combine #
3 with separate when the body becomes to large. 

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com