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

[stt@houdini.camb.inmet.com (Tucker Taft)]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:

: Here is the reasoning behind the Eiffel approach to
: separating interface from implementation. It was designed
: in full knowledge of the Modula-2/Ada-83 mechanisms, in an
: attempt to draw the lessons of both their advantages and
: limitations, taking advantage of newer software technology
: and of O-O principles...

In my experience, separating the spec and body physically is
extremely advantageous, and the need to have redundancy between
the spec and body is an important feature in a multi-person
project, not an "inconvenience."  In Ada (and to some extent in C/C++
when you use header files in a disciplined way), changing the interface
to a public routine, or adding a new public routine, or removing
one, is a fundamentally different kind of operation, and *intentionally* 
requires more effort and care.


: ...
:         G5. Minimize the programmer's work. In particular
:             it is crucial to avoid forcing the programmer
:             to duplicate text. Duplication is almost always
:             bad, especially with respect to ease of maintenance,
:             one of the central goals of software engineering.
:             It also hampers reuse, reliability (when you
:             duplicate code, you duplicate its bugs, and
:             the more software you write the more likely
:             it is that it will include bugs), and ease
:             of change.

Basically, this is the paragraph I don't agree with, since the
"duplication" one is talking about is duplication of the
parameter/result/constraint profile in the spec and body of 
a package/class.  The compiler checks for conformance, so the issue
of forgetting to fix bugs in all copies doesn't arise.  The compiler
catches such gaffes.  On the other hand, duplicating a chunk of
algorithmic code in two places is undeniably bad news.  But we
aren't talking about that here.

The programmer's work spent duplicating the interface in the
spec and body is truly trivial, whereas the advantages of having
a physically separate interface are profound in a multi-person
(or just long-lived) project.

I can believe this is somewhat just a matter of personal taste,
and where one believes programmers should put their energy.
However, there are some interesting anecdotes about programmers
who go from a language like Fortran or old-style C where there
is often no separate spec, to a language like Ada or Modula with
physical separation.  They suddenly realize that the spec is itself
an important design object, something for potential users and
implementors of an abstraction to work on together early in a project,
and something which will allow users and implementors of the abstraction
to go off and work relatively independently once agreement on the spec
is reached.  It becomes very clear that the spec is not "owned" by
either the users or the implementors, but is rather the contract between
them which will thereafter change only through collaborative renegotiation.

: -- 
: Bertrand Meyer, President, ISE Inc.
: ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
: 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
: http://www.eiffel.com, with instructions for download

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA