Jim Fulton writes:
Dieter Maurer wrote:
I cannot see, why the separation of interface and implementation should make the contract stronger.
The interface *is* the contract. If someone builds a house for me, I don't want the house to *be* the contract. I want the house to adhere to the contract. Interface/contract and implementation are two qualitatively different things. But this does not imply, that the contract becomes stronger, when interface and implementation are separated. Packaging issues do not change the contract.
I see however, that you usually will (should) start with a specification (the interface is part of it) and then provide an implementation (or more than one) for it.
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.
We disagree then. A weak interface that is satisfied by definition is nearly useless to me. If an implementation has nothing to do with its specification, then either the implementation or its specification is useless, at least in relation to one another.
But, you note, that I did not speak about "a weak interface that is satisfied by definition" but about a "somewhat weaker contract that is met by the partners compared to a somewhat stronger contract but violated contract".
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).
I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions. If the implementation decisions are essential: e.g. linear versus logarithmic time complexity, I would like to have that stated in the documentation.
Note also that most classes implement multiple interfaces. Generating interfaces from classes trends to yield bloated non-cohesive interfaces. I may agree with this. Though some configuration for the generation process may help to reduce the danger.
Similarly, most interesting interfaces are implemented by multiple classes, so nearness to implementation is not really meaningful. It helps the implementation to adhere to the contract.
Please note that these points were argued extensively on the Python types-sig a couple of years ago. SIG archives tend to be non-searchable. I, probably, will not dig in to summarize the results. Even, if I do, this would be no garantee that I would be convinced.
Let me stress my point of view. Maybe, we are not too far away from one another: * I like clear specifications (as you do) * The specification has more value, when its implementations adhere to it (you probably will agree). * A documentation about an existing system is more valuable, when it states what is rather than what should be (here we may disagree). I usually start by studying the documentation. If it descibes what is, then I will recognize early what does not fit my requirements and can work around it. If it describes what should be, I will determine the deficiencies much later in my projects, modifications are much more difficult and expensive. * Having the specification near the implementation helps the implementors to adhere to it, especially with long maintenance periods. (Here we may disagree). I believe in the value of well documented source, in literate programming. Dieter