Re: Object Oreinted Style

Re: Object Oreinted Style

[Dale Stanbrough]

Michael Garrett wrote:

> 
> In "Object Oriented Software in Ada 95" Michael A. Smith uses the package 
> as
> a "class" construct, putting one tagged type and it's associated 
> operations
> into a single package, and derived types in there own top level ( NON
> child  ) packages. He warns against breaking encapsulation rules by 
> deriving
> types in child packages. In the booch components, derived types are 
> declared
> included in child packages. In a large embedded system, which method 
> would
> make for more maintainable
> code, one type per package, or a "class" multiple derived types?



Packages are (almost) orthogonal to the concept of type in Ada.
You can construct an OO hierachy in Ada by declaring every single
type in a single package.

At the other extreme you could declare each type in a single package,
where the packages are not related to each other (apart from the 'with'
relationship required so you can declare a child type).

The questions you have to ask are 

   "what sort of changes am I likely to make in the future"

and

   "what is the best way to package these things so that people
    will be able to easily understand and navigate around my large
    program"


Def. child packages "open up" the full view of a parent type declared
in a parent package, and in this regard invite abuse by preventing
total encapsulation.

On the other hand hierachical packages are a wonderful mechanism
for dealing with understandability in program design.

On the balance i'ld be inclined to go with hierachical packages
(and perhaps you could invest in some ASIS developement to ensure
your programmers don't abuse the "opened" types too much).


Dale

Object Oreinted Style

[Michael Garrett]

I have seen two philosophies concerning "class" construction in Ada95.

In the RM, a class is defined as:

Class.  A class is a set of types that is closed under derivation, which
means that if a given type is in the class, then all types derived from that
type are also in the class. The set of types of a class share common
properties, such as their primitive operations.

and Package as:

Package.  Packages are program units that allow the specification of groups
of logically related entities. Typically, a package contains the declaration
of a type (often a private type or private extension) along with the
declarations of primitive subprograms of the type, which can be called from
outside the package, while their inner workings remain hidden from outside
users.

In "Object Oriented Software in Ada 95" Michael A. Smith uses the package as
a "class" construct, putting one tagged type and it's associated operations
into a single package, and derived types in there own top level ( NON
child  ) packages. He warns against breaking encapsulation rules by deriving
types in child packages. In the booch components, derived types are declared
included in child packages. In a large embedded system, which method would
make for more maintainable
code, one type per package, or a "class" multiple derived types?

--
Michael C. Garrett
Vice President Research and Development
Medical Research Laboratories
www.mrlinc.com
michaelgarrett@csi.com

Re: Object Oreinted Style

[Magnus Larsson]

In article <dale-617BD4.22171828032000@news.rmit.edu.au>,
Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
[.....]
>
> Def. child packages "open up" the full view of a parent type declared
> in a parent package, and in this regard invite abuse by preventing
> total encapsulation.
I am by no means an expert in this area, but isn't a "private package"
a solution here?
like :
package Parent is
type Base_Type is....
...
end Parent;
private package Parent.Child is
type Derived_type is new Base_type.....
...
end Parent.Child;
Or have i completly missed the point here? I thought this construct does
exactly this and "closes" any direct access to the child.
Magnus
> Dale
>
--
.|,
-o----
mla@omicron.se


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Object Oreinted Style

[Dale Stanbrough]

Magnus Larsson wrote:

> In article <dale-617BD4.22171828032000@news.rmit.edu.au>,
> Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
> [.....]
> >
> > Def. child packages "open up" the full view of a parent type declared
> > in a parent package, and in this regard invite abuse by preventing
> > total encapsulation.
> I am by no means an expert in this area, but isn't a "private package"
> a solution here?
> like :
> package Parent is
> type Base_Type is....
> ...
> end Parent;
> private package Parent.Child is
> type Derived_type is new Base_type.....
> ...
> end Parent.Child;
> Or have i completly missed the point here? I thought this construct does
> exactly this and "closes" any direct access to the child.


A private package can still see the full declaration of the type
defined in the parent package. This is what i meant by the private
type being "opened up" again (this is terminology borrowed from
Betrand Meyer really).

For example...

   package Parent is...

      type Base_Type is tagged private;
   private
      type Base_Type is tagged
         record
            X : integer;
         end record;
   end Parent;


   package Parent.Child is
      type Derived_Type is new Base_Type with private;

      procedure Clear_All_Fields (Item : Derived_Type);

   private
       etc.
   end;

In the body of Parent.Child procedure Clear_All_Fields can
change the value of the field X, despite it being declared 
private. Making Parent.Child doesn't prevent this from
happening.


Private packages are useful, but only to an extent. They prevent
compilation coupling (changing a private packages spec will never
require the recompilation of a package outside of the hierachy),
but fail to provide the sort of support for abstractions that i'ld
like to see (the completion of a private type in a public package
being derived from a type declared in a private package). I find
them frustratingly limiting for this reason.
Of course this is in constrast to "private" types inside packages, 
which do not prevent compilation coupling, but are used to support
abstractions!


Dale

Dale

Re: Object Oreinted Style

[David Botton]

Could you post an example of this.
DB

Richard D Riehle wrote in message <8c68ma$cef$1@slb3.atl.mindspring.net>...

>Actually, with clever use of access declarations, one can do exactly
>what you have just described under the model of an opaque type.  I have
>been experimenting with just this kind of thing to see how far it
>can be stretched.

Re: Object Oreinted Style

[Richard D Riehle]

In article <dale-45215C.21580231032000@news.rmit.edu.au>,
	Dale Stanbrough <dale@cs.rmit.edu.au> wrote:


>Private packages are useful, but only to an extent. They prevent
>compilation coupling (changing a private packages spec will never
>require the recompilation of a package outside of the hierachy),
>but fail to provide the sort of support for abstractions that i'ld
>like to see (the completion of a private type in a public package
>being derived from a type declared in a private package). I find
>them frustratingly limiting for this reason.
>Of course this is in constrast to "private" types inside packages, 
>which do not prevent compilation coupling, but are used to support
>abstractions!

Actually, with clever use of access declarations, one can do exactly
what you have just described under the model of an opaque type.  I have
been experimenting with just this kind of thing to see how far it
can be stretched.

In this case, the opaque type is an incomplete declaration in the private
part of one package, The full type is a private type in a private
child package and an access type points to the incomplete type. The
full completed declaration, within the package body is a derivation
from the type in the private package specification.  It can even be 
another level of indirection via an access type.

With this technique, one could modify the content of the body,
extend the type in the body at will, and still have the benefits 
of a tagged type at the specification level for more extensions 
throughout the children rooted at the same level.  Now we have a
robust design using Meyer;s "open/closed principle."

This is also a good technique when creating a  classwide package, one
that has only classwide operations in it that need to be implemented
using data common to the entire parent-child hierarchy.

Richard Riehle