Private Specifications

Private Specifications

[Stephen R. Willson]

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?

-- 
 Stephen R. Willson           willson@seas.gwu.edu          (202)-395-4922
               ** Get outa the way de .. kachunk .. er! **

Re: Private Specifications

[Bob Kitzberger]

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

Re: Private Specifications

[Mark A Biggar]

In article <1993Jan30.034333.14737@seas.gwu.edu> 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?

It allows for the complete hiding of the implementation of an Abstract Data 
Type.  For example, lets use the usual example the stack data type:

generic
	type ITEM is private;
package Stacks is
	type Stack is Private;

	function CREATE return Stack;
	procedure Push(S: Stack; I: ITEM);
	function Pop(S: Stack);
	function IsEmpty(S: Stack);

	exception StackUnderflow;
	exception StackOverflow;
private
	type StackImp;
	type Stack is access StackImp;
end Stacks;

Notice that nothing about the implementation of a Stack is visible outside
the package even to the compiler.  So now I can have alternative bodies
as implementations:

package body Stacks is
-- linked list implemetation
--   exception StackOverflow probably never happens
	type StackImp is record
		I: ITEM;
		Next: Stack;
	end record;
...
end Stacks;

or

package body Stacks is
-- bounded array implementation
--   exception StackOverflow is very possible
	subtype StackIndex is Integer range 0..100;
	type StackBody is array 1..100 of ITEM;
	type Stack is record
		ToS: StackIndex := 0;
		Store: StackBody;
	end record;
...
end Stacks;

Switching to either of the above package bodies requires that I only recompile
the body and relink my program.  If the definition of the stack had been
in the private part of the package spec, switching implementations would
have required recompiling every unit the instantiated the package or depended
on a such a unit.  When a type is defined in the private part of a package,
it is only logically hidden from the user, its representation still affects
othe units that depend on the package, while something in the package body
never has affect on anything outside the package.

--
Mark Biggar
mab@wdl1.wdl.loral.com