X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 88.191.16.109 Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!nospam.fr.eu.org!usenet-fr.net!fdn.fr!proxad.net!feeder1-2.proxad.net!74.125.64.80.MISMATCH!postnews.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe02.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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Lines: 37 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Thu, 05 May 2011 22:20:56 UTC Organization: Public Usenet Newsgroup Access Date: Thu, 05 May 2011 19:20:54 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3612 On 11-05-05 06:21 PM, Lew wrote: > On 05/05/2011 04:14 PM, Jim Janney wrote: [ SNIP ] >> 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. > Well, no. The OP has stated that he needs the map to obey the contract of LinkedHashMap: "where I'm creating sortedMap above, I need the map to retain the insertion order". This is the normal behaviour of LinkedHashMap, that its predictable iteration ordering is insertion-order. If he wants a map that has this iterator ordering, he wants LinkedHashMap (and possibly no other maps qualify actually; I am not 100% certain on this). It would be a mistake for the OP to write an API method that returns a Map when just any Map won't pass muster. It's not that _his_ method won't do the right thing, but that the client code that gets a Map will be written to Map, and eventually at some point some other Map implementation will get used instead. As it happens this example highlights one main thing that interfaces don't do, which is to prescribe implementation contracts. Classes do that; interfaces can't. And in this particular case there is not even an available superclass that also satisfies the implementation contracts. So LinkedHashMap is appropriate. AHS