Michel Pelletier writes:
> Also, defining the interface seperately keep the two things apart,
> impementation and interface, and doesn't allow you to sneak in a new
> method unless you also sneak it into the interface, thus making a
> stronger "contract" with the user.
I am a bit astonished by this statement:
I know the "design by contract" concept from Bertrand Meyer,
the Eiffel developper.
In Eiffel, essential parts of the contract, among others
method prototype, pre- and post-conditions as well as invariants
are build directly into the language.
A documentation tool extracts these parts
from the source to generate the interface, for people
that are only interested in how to use the class/method.
Programms can be executed in a way, that the various
(executable) contract parts can be checked at runtime.
*THIS* provides for quite a strong contract.
I cannot see, why the separation of interface and implementation
should make the contract stronger. I do see, however, that it
makes it more likely to be broken by the implementation.
It is a very good thing to have the specification very near
to the implementation -- as a permanent guide to the
implementor. It is even better, when big parts of the
specification becomes part of the executable code
(as is the case for Eiffel's pre- and post-conditions).
If you want to prevent your implementors to change the
interface specification, generate the interface for the
implementation and compare against your master copy.
In my view, it is better to have a somewhat "weaker" contract
that is met by the partners than a "stronger" contract that
is violated. Or, to say it differently, it is more essential
the a system's documentation describes faithfully what is
rather than what should be (but is not).
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -