From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,21e68c5e7e9adc04,start
X-Google-Attributes: gid103376,public
From: mcriley@bix.com (Marc A. Criley)
Subject: OO vs Reality:  An Ada 95 Solution?
Date: 1996/12/14
Message-ID: <58ue6j$b4l@nw101.infi.net>#1/1
X-Deja-AN: 204097959
organization: InfiNet
keywords: OO, Reality, Ada 95, Child packages
newsgroups: comp.lang.ada
summary: Can child packages solve an OO dilemma?
Date: 1996-12-14T00:00:00+00:00
List-Id: <comp.lang.ada>


OO vs Reality:  An Ada 95 solution?

A dilemma often occurs when implementing an OO solution to a particular
implementation problem.  Given a well-defined, cohesive class, the
preferred Ada implementation is to implement the class within a single
package.  The class attributes are defined as private, limited, private, or
hidden in the body, as appropriate.  The operations (or services or methods
or whatever) are defined in the package spec to permit manipulation of
class objects.

The problem arises when some small bit of information about this class is
needed by another, such as the values a particular attribute may hold.  The
entire class in which those values are defined gets dragged along with that
type definition.  One might argue that smart compilers/linkers/code
strippers can remove the unnecessary code, but I feel that misses the
point.  Why should all the operations be brought in when all that's needed
is (for instance) an index range?

The needed attribute type definition could be pulled out of the class and
placed in a (gasp!) common types package, but where does that end?
Eventually most of the types get migrated to such packages, with only
attribute declarations and operations remaining in the now not-so-cohesive
class package.

Utilizing Ada 95's child packages could provide a compromise solution (or
bastardization, depending on how you look at it. :-)  The following is
submitted for discussion:

A package is created to contain the class' attributes (if appropriate),
accessors, constructors, destructors, and _very_ primitive operations,
i.e., the class is effectively useless without them.  A child package is
then created to supply the specifications for the class operations.  This
permits those other classes that need only access to attributes or their
type definitions to simply "with" the parent package, while those classes
that do more extensive manipulation can "with" the child package.
Cohesiveness is maintained, albeit in a parent-child package relationship,
which Ada 95's semantics bind far more closely than with the usual types
package/procedures package relationship.

This seems to me to be a good compromise, that is, I'm not totally ga-ga
over it, but it does seem to resolve the dilemma rather effectively.  I'm
interested in comments, criticisms, and earlier references to this
technique.

One last note: To be able to migrate to this technique when one is
currently using Ada 83, the appropriate implementation is to collect all
attributes and operations into a single package and just live with the
excess for now.  When the time to migrate to Ada 95 arrives, it becomes a
mostly mechanical process to split the class package into parent and child,
and then change references to the operations to reflect their new location
in the child package.

Marc A. Criley
Software Practitioner

OOA = (Re)packaging, OOA /= Decomposition