Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe21.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <2psjssq4zj.fsf@shell.xmission.com> <2poc3gq3p2.fsf@shell.xmission.com> <2pk4e4q2sq.fsf@shell.xmission.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 73 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Thu, 05 May 2011 22:49:22 UTC Organization: Public Usenet Newsgroup Access Date: Thu, 05 May 2011 19:49:20 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3618 On 11-05-05 07:02 PM, Daniele Futtorovic wrote: > On 05/05/2011 23:02, Jim Janney allegedly wrote: >> Daniele Futtorovic writes: >> >>> On 05/05/2011 22:42, Jim Janney allegedly wrote: >>>> Daniele Futtorovic 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 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. AHS