To interface or not to interface

[Walter Bright]

Steven Schveighoffer wrote:
> It's a logical conclusion.  You provide a map-type collection, call it a 
> HashMap.  Then, a UI designer wants to abstract his specific Map-like 
> container that exposes his elements, so you provide him a Map 
> interface.  But HashMap implements all the required functions to be able 
> to implement the Map interface, so you slap Map on the back of the class 
> definition, and presto!  It implements the map interface.  Where's the 
> extra complexity?

The extra complexity is in the container supporting very different ways to do 
the same thing.

> I don't see how that's a bad thing.

If the user wants an interface, he can add one on to the front of the 
collection. It doesn't need to be in the collection itself.

The "bad" thing is the component integrating in capability that is easily done 
as an add-on.

This reminds me of a fellow I worked with years ago who would provide both a 
free-function interface and a class interface to each of his components. It was 
completely redundant to do both, and added pages of complexity and documentation.