To interface or not to interface
newshound1 at digitalmars.com
Mon May 24 14:11:49 PDT 2010
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.
More information about the Digitalmars-d