|There's more than one way to do things|
Re^5: OO-style modifiers for 'sub' ?by dpuu (Chaplain)
|on Feb 01, 2003 at 00:37 UTC||Need Help??|
OK, I'll admit that I went of at a bit of a tangent there. But since we're here, let me refute your example: an interface named "PitchControl" would be no less ambiguous than a method named "set_pitch". We can't use the ambiguity argument to support explicitly named interfaces.
But you are right. The discussion shouldn't be about whether it is valid to infer an interface from the body of the implementation of a client (a la templates): its about whether it is valid to infer an interface from the functions supported by an object. That is: we're talking about the dependency structure:
The second example states that an object implements the interface if it supports a specific set of methods. It says: "if it looks like a duck, and quacks like a duck, and walks like a duck: then lets assume that it is a duck".
In both cases, the interface is made explicit. Client code can be written to require an object that implements a specific interface: the interface is explicit from the client's point of view. The binding between the object and the interface is also explicit, but the direction of the dependency is different.
But your original question still stands: why would we want to break the explicit dependency between the class definition and an interface?
Imagine you have a blob of 3rd party code that has an overly fat interface. You can't modify this code (e.g. you're not sysadmin). You want to use these blobs in you own code, which uses a much thinner version of the same interface. You want to validate your input (i.e. does the input object implement your thin interface) without modifying the source code of an object that implements the fat interface.
fanfare: Inferred Interfaces to the rescue! --Dave