Re: "Program to an interface" - When to break a design pattern
Joshua Cranmer wrote:
Zapanaz wrote:
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,
then you've declared the wrong type, duhh. Did you read the link you cited?
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.
It's still the same map, whether you return it as a Map or as a LinkedHashMap.
That is, the same iterator will still be called, and will still return the
elements in the same order independent of how it was called.
If you're worried that a later developer might not see that it is in the
proper order, you can include it in the documentation. Or perhaps return
SortedMap instead ;-).
If the need is for a sorted map, then the design principle mandates that the
declared type be 'SortedMap'. Period. Declaring the variable as 'Map' could
lead to troubles, e.g., accepting an assignment to point to an unsorted map.
This would be the very same prinicple the OP cited, BTW, not some odd
variation thereof. The notion that the principle calls for the declared value
to be 'Map' when it should be 'SortedMap' is just a stupid misinterpretation
of the principle.
Programmers are supposed to be smart and to think, not to be stupid and
superstitious.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg