Re: "Program to an interface" - When to break a design pattern
On 05/05/2011 04:14 PM, Jim Janney wrote:
Zapanaz<http://joecosby.com/code/mail.pl@foo.com> writes:
I've seen this design pattern before
http://witte-consulting.com/documents/design-principles/
and, in general, I see the point of it.
But say we've got something like this
LinkedHashMap<String, Integer> sortedMap = this.getSortedMap();
So you have the method
public LinkedHashMap<String, Integer> getSortedMap() {
//do stuff
}
(not necessarily public)
Now the design principle says, the method signature should instead be
public Map<String, Integer> getSortedMap() {
//do stuff
}
The problem is, where I'm creating sortedMap above, I need the map to
retain the insertion order. If what's returned actually is a Map,
rather than a LinkedHashMap, then the results the user actually sees
are going to be in the wrong order. Making things worse, in this case,
nothing would actually break, only the end user would notice anything
was actually wrong.
So in this case, it seems to me, that using LinkedHashMap in the
method signature makes sense. The fact that the return retains the
insertion order is an integral part of what the method does.
If nothing else, it's going to save Fred Developer down the line from
looking at the code around this
Map<String, Integer> sortedMap = this.getSortedMap();
and thinking "wait, how do I know getSortedMap() is going to return a
result with the right ordering?", and having to waste time digging
into that method.
'SortedMap', as so many have said. Apparently you need to practice study of
the API docs much, much more. We all should know the essential collections
types. Get studying!
The point of programming to the interface is to make it easier to
substitute a different implementation, which implies that any reasonable
implementation can be used. If this is not true, if the code that uses
the object relies on behavior only found in one implementation, then
there is no benefit to using the interface, and you make it more
inviting for someone to break things later on. So in this case, no,
programming to the interface would be the wrong thing to do. The point
of design principles is to make you think before you break them :-)
Actually, in this case programming to the interface is the /right/ thing to
do. Please don't mislead the OP.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg