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

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

In article <3404909F.2C67412E@eiffel.com>,
Bertrand Meyer  <Bertrand.Meyer@eiffel.com> wrote:
>
>The goals are clear:

  I agree with most of these goals, but I have an issue with one
of them:

>        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.

  Of course duplication is bad, but this is a special case which
is not nearly so bad.  These, if I understand, are your reasons
for disliking code duplication:

 1. Too much typing
 2. Duplicate code duplicates bugs
 3. More code means more bugs
 4. Too hard to change

  Here's why I don't think any of these are serious problems here:

 1. The same tools which provide interface files for documentation
   in Eiffel could provide them for compiler usage in another
   language, so there is no more typing than in the Eiffel approach.

 2. This is true, but is no more a problem than a single bug in this
   case because if the bug is fixed in one place, the compiler will
   force us to fix it in the other place.

 3. Certainly, given two independent code fragments, the total
   expected number of bugs would be greater than that of a single
   fragment.  But in this case, the fragments are not independent:
   if the implementation (which includes the interface) is bug-free,
   then so is the interface.  If the interface has a bug, then so
   does the implementation; but this is really one bug as argued
   in #2.  So by adding an interface file, we haven't added any
   extra potential for bugs.

 4. The interface of a class is the part that the rest of the
   system relies on.  Perhaps it should be hard to change.  I
   think there is merit in making a programmer aware that certain
   changes could have repercussions outside the module in
   question.  So, while true, point #4 may not be a problem at all.

Having said all that, I'm not particularly in favour of one method
over the other.  To me, it seems like a very minor issue compared
with the complexities programmers have to deal with.  I don't
think the one-file-versus-two issue has any real lasting effects
on the development process.

One last argument...

In Eiffel, a short form can be produced for documentation.  Why not
give the compiler the capability to ensure that the short form
matches the code being compiled?  And if we do that, aren't we
back to the separate-interface-file model again?

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