Re: Need advice re package organization.

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3F228F3B.9020203@attbi.com...
> Bobby D. Bryant wrote:
>
>  > Any suggestions, either for my specific example or for more general
>  > considerations?
>
> The "right" answer to this question tends to be heuristic.  One package
> is probably too few, one (child) package per final type may be too many.
>
> If your (final) object types are going to be composed of component
> types, you almost certainly want one set of packages of components, and
> another of objects.  I would start with that organization, and
> specialize using child packages if there are types that are difficult to
> implement, not generally used, or where collisions between operation
> names are going to cause problems when you have a use clause for the
> main package.
>
> Figuring out the best organization is tough, and often you will discover
> a problem with the hierarchy you have chosen once you start implementing
> it.  Don't worry, go ahead and change it.  That is what text editors are
> for.  You don't need to find the perfect decomposition, just avoid bad
> ones.  And a bad decomposition shows up when it starts making work for
> you, rather than eliminating it.
>
> Of course, whatever organization you choose, you should sketch it out
> first, write the package specs, the main program, and then the package
> bodies.

All of this is good advice. When structuring your packages, keep in the
back of your mind the visibility and access rules that Ada insists upon.
For example, you'll have to avoid any circular package references (a
poor hierarchy will have a package trying to with a package that has
already been with-ed by it, creating a circular dependency). Another
catch may be a "support" package, that cannot gain access to the
necessary types of a set of parent/child packages (due to circular
references).

Parent/child package relationships themselves can get tricky. From a
software design perspective, you want to limit visibility for safety,
and yet the child packages enjoy full visibility of the private parts
of the parent. Yet, when the same package is moved outside of
the parent/child hierarchy, you enjoy the limited visibility you want,
but then you may not have the visibility to types and API's that you
might need.

[As a side note, I sometimes wonder if an enhancement to the Ada0Y
language might be to be able to specify a limited visibility of a
parent package's object's internals (a la not "protected" type in
C++). A protected class in C++ allows derived code to mess with the
internals, whereas normally the parent object's elements are a
black box. Use of limited visibility helps to reduce code coupling.]

I have found the object relationships are easier to define, and these
should perhaps be done first (perhaps initially as one package). After
this has been "purified/tested", then see how this can be broken down
into separate and perhaps "optional" packages and child packages.

Package visibility rules make the packaging more difficult, in my own
experience. Obviously if the project is huge, you'll want to define
the objects and package hierarchy up front (for sanity and quicker
development). It might also be stated that this is good practice
anyway, and should always be done this way.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg