Re: "Program to an interface" - When to break a design pattern
On 06/05/2011 00:49, Arved Sandstrom allegedly wrote:
On 11-05-05 07:02 PM, Daniele Futtorovic wrote:
On 05/05/2011 23:02, Jim Janney allegedly wrote:
Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid> writes:
On 05/05/2011 22:42, Jim Janney allegedly wrote:
Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid> writes:
On 05/05/2011 22:14, Jim Janney allegedly wrote:
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 :-)
Entirely disagreed. The code shown did not contain any
justification for
breaking the pattern in question, and on the opposite, it contained
all
the reasons to think more about encapsulation, which is the true
underlying rationale for coding to interfaces -- not polymorphism
per se.
The justification is not in the code shown, but in the accompanying
remark "I need the map to retain the insertion order." There's no
interface in the JRE that promises this, and only one class that
provides it, which makes encapsulation, shall we say, difficult.
That's not the point! Yes, you need a LinkedHashMap to retain
insertion order in a Map. But retaining insertion order is
relevant... only when inserting.
Think a minute. When does retaining insertion order actually matter?
When you build the map, or some time later when you iterate over it?
Hint: if you never iterate over it, the order doesn't matter at all.
I don't need a full minute to see that this is even further beside the
point.
Yeah, as in, your argument is incorrect, and Jim is right.
You see this bit from the LinkedHashMap API?:
"This implementation spares its clients from the unspecified, generally
chaotic ordering provided by HashMap (and Hashtable), without incurring
the increased cost associated with TreeMap. It can be used to produce a
copy of a map that has the same order as the original, regardless of the
original map's implementation."
"Spares its _clients_". You provide this implementation for the
_clients_. Just any Map won't do, Daniele. And if you "program to the
interface" blindly, and return a Map from this method, then as long as
the OP's _unchanged_ code is used to implement
public Map<String, Integer> getSortedMap()
then we'll get a LinkedHashMap and obey the desired contract. But down
the road - since we've failed to specify the requirement - things could
change, and the original implementation requirement be violated. In fact
a maintainer will look at the method's return type, and the
(unfortunate) name of te method, and in the absence of design
documentation decide maybe to use a SortedMap implementation instead.
*Which would be a mistake*...but your recommended approach would
encourage him to do it.
Don't get all blinded by design principles like "program to the
interface". Most of the things you access in a real-world complex
application are exposed through classes, not interfaces.
I can't say I take too kindly to your assertion that I intervened as I
did for the sake of blindly following anything.
Neither do I agree with your interpretation of the bit of Javadoc you
quoted. No, you do not provide a LinkedHashMap to clients. You provide a
Map with the same iteration order as another. Nuance.
The return type being a LinkedHashMap, itself, doesn't tell you
_anything_ about its iteration order. Take the following code:
################################################
interface Function<K, V> {
V f( K k );
}
static <T> LinkedHashMap<T, V> map( Map<T, U> input, Function f ){
Map<T, V> ret = new HashMap<T, V>();
for( Map.Entry<T, U> entry: input.entrySet() ){
ret.put( entry.getKey(), f.f( entry.getValue() ) );
}
return new LinkedHashMap<T, V>( ret );
}
Q: What does the return type tell you about the iteration order of the
returned instance?
################################################
Like it or not, only the method's *contract*, if anything, can guarantee
you that the returned instance will iterate in the same order as the input.
And all this has squat to do with my calling Jim's last reply beside the
point.
Jim correctly quoted the OP saying: "I need the map to retain the
insertion order". Given that constraint, it is irrelevant to question in
which cases retaining insertion order matters or not. Which he did
afterwards. In reply to which I said it was beside the point.
--
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"