Re: Interface/Implementation (was Re: Design by Contract)

[doylep@ecf.toronto.edu (Patrick Doyle)]

Ok, I've never used the "short" tool, but here's how I understand it...


In article <340C85CE.6F42@link.com>, Samuel Mize  <smize@link.com> wrote:
>
>Some capabilities that are provided by Ada's separate spec/body
>approach are:
>
>* Different order of subprograms -- one order or grouping may be
>  most meaningful for the interface, another for implementation.

Short can't do this.

>* Unexported (local to the package) subprograms and declarations.

Short filters out unexported features, and even aspects of assertions
which refer to unexported features.

>* Different comments -- the Ada spec usually contains comments that
>  describe what facility a subprogram provides and how to use it,
>  the package contains a description of its implementation details.

The Eiffel class definition would contain all comments, written
in certain standard ways which allow Short to filter out the
implementation comments and retain the interface comments.

>* Interface control and verification -- the Ada spec can be written
>  and published, and other groups can code against it.  If the
>  implementation or the client changes, the compiler can verify that
>  they are still consistent without having to reprocess both.

Short won't help much here, but IMO abstract (deferred) classes
can do this anyway.  (However, the debate is raging in another
thread...  :-)

>* Multiple interfaces -- you can have several sub-packages that
>  export subsets of a package's functionality.  In Ada 83, if
>  visibility into the body (implementation) is required, these
>  must all be contained in the main package's spec; in Ada 95,
>  they can be separate child packages.  In either case, if you
>  just want to re-package existing functionality to provide
>  different views, you can provide "view" packages that rename
>  elements from the main ("full-view") package.

Eiffel has selective export which allows a class to export
features to specific clients.  Eiffel also has multiple
inheritance, which allows a class to support different
interfaces which are expressed as abstract classes.  The
"view" packages are really nothing more than the GoF
"adapter" pattern which can be accomplished in any
OOP language.

>* Multiple implementations, global, compile time -- you can have
>  many implementations of your package spec, and select the best
>  one for your application at compile time.  Thus, your "list"
>  could have a hash table for faster lookup, or store its contents
>  to disk to allow long lists of huge data items (just one in
>  memory at a time), or whatever -- as long as the spec stays the
>  same, the client code doesn't need to be recompiled.

There are design patterns which deal with this nicely (eg. Factory
Method) without having to add this functionality explicitly to
the language.

>* Multiple implementations, item-specific, compile time --
>  Ada generics can provide a unified interface for several
>  implementations of a facility.  Any logic that is common across
>  all the implementations is written into the generic, while any
>  code that is implementation-specific is provides as subprograms
>  that are parameters to the generic.  In the worst case, the
>  generic only provides a "template" that instantiations must
>  follow.  For example:
>
> [example]
>
>  This generic just encapsulates an interface.  If you write clients
>  that instantiate it, and implementation packages that can be used
>  to instantiate it, then you know any client can switch to any
>  implementation with a simple, compile-time change to the client
>  code (where it instantiates the generic).

Again, these are design patterns (eg. Template Method) which can
be done in any OOPL with polymorphism.

>* Multiple implementations, run time -- these are best supported in
>  Ada by dispatching subprograms and tagged types, not by packaging.

More design patterns (eg. State).

In the cases where I simply said that what you were talking about
is a design pattern, this means that special language features
are not necessary to do these things.  Perhaps it's nicer to have
the language help you out with these design patterns?  I don't
know.  But I think there's a lot of value to Eiffel's simplicity
and orthogonality which allows you to put together constructs
in an intuitive manner which can achieve these things.

A matter of opinion, I suppose.

 -PD


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca