From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_20,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 31 Jan 93 07:41:40 GMT
From: rlk@VisiCom.COM (Bob Kitzberger)
Subject: Re: Private Specifications
Message-ID: <274@visicom.com>
List-Id: <comp.lang.ada>

willson@seas.gwu.edu (Stephen R. Willson) writes:

>I am not sure I understand the purpose of placing a type specification in
>the body of a package, as a way to "hide" the specification from the
>"client".  Does someone have an example of where someone would want to
>hide the type in such a way?

[...climbing to the ivory tower ...]

This is one of the ways that Ada supports good software engineering
practices: information hiding and data abstraction, which lead to
loose coupling and tight cohesion.

Any reasonable software engineering text will give many a justfication
for information hiding and data abstraction.   Basically, the justifications
are along these lines:

   1. The abstract 'external' behavior of objects is of importance to users
      of the object, while internal implementation details are not.
      Users of a bounded buffer (usually) don't care how it is implemented
      internally.  If they do care, then it is best to provide this information
      via documentation (e.g. O(n) notation to describe runtime complexity)
      via commentary in the specification, rather than letting 'em have a
      peek in your knickers.

   2. Placing object implementation details (i.e. type implementation details)
      makes it more difficult to change the implementation later on without
      rippling the effect throughout your system.  If you place type details
      in a package specification, then it is quite possible that clients
      will poke around in the internals of the object.  Any changes you
      make will have to be resolved with these clients.  This is known
      as tight coupling (between objects).

   3. In order for the human mind to deal effectively with very complex
      systems, we resort to abstractions: extracting the essence of
      an objects behavior at a certain level (i.e. a car's ability to
      accelerate whenever the gas pedal is depressed) while hiding
      details that are not important at that level (i.e. the driver
      not having to think about gas pedal linkages, cylinder movement,
      ignition of pressurized gas, etc.).

In the analysis and design phases, you only (should) care about the
behavior of objects and subsystems, and think about internal implementation
details only in risky, 'untried' areas of a project.   Later, in the
coding stage, you fill in the details.  Keeping the implementation details
hidden formalizes the separation of specification and implementation,
mimmicking the way you develop systems.  

Check out Booch's "Software Engineering in Ada" for many examples.

[...climbing down from the ivory tower...]

One of the standard ways to hide implementation details is:

  package Object_Manager is
     type Some_Object;
     procedure Create( Obj : out Some_Object );
     procedure Behavior_One( Obj : in Some_Object );
     procedure Behavior_Two( Obj : in Some_Object );
     function Is_Green( Obj : in Some_Object  ) return Boolean;
     ... list all behaviors
  private
     type Object_Implementation;
     type Some_Object is access Object_Imeplementation;
  end Object_Manager;

The details of the object's implementation (i.e. the type's guts)
are placed in the body, where they can be changed, mutilated, and
played with to your heart's content, without changing the specification.
          

Hope this helps,

  .Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888