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