From: rlk@VisiCom.COM (Bob Kitzberger)
Subject: Re: Private Specifications
Date: 31 Jan 93 07:41:40 GMT [thread overview]
Message-ID: <274@visicom.com> (raw)
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
next reply other threads:[~1993-01-31 7:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1993-01-31 7:41 Bob Kitzberger [this message]
-- strict thread matches above, loose matches on Subject: below --
1993-01-31 8:42 Private Specifications Mark A Biggar
1993-01-30 3:43 Stephen R. Willson
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox