Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Fri, 06 May 2011 02:28:51 +0200 Organization: A noiseless patient Spider Lines: 68 Message-ID: References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <2psjssq4zj.fsf@shell.xmission.com> <2poc3gq3p2.fsf@shell.xmission.com> <2pk4e4q2sq.fsf@shell.xmission.com> <2py62kohyi.fsf@shell.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 6 May 2011 00:29:10 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="3L0fosuCYLsM9cW5CzHNyA"; logging-data="24778"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FczB0lJyfjzUnLV0yfmfR" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: <2py62kohyi.fsf@shell.xmission.com> Cancel-Lock: sha1:hzNAM8Jja02yMaiECikaP32jlQ8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3630 On 06/05/2011 01:17, Jim Janney allegedly wrote: > Daniele Futtorovic writes: > >> 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. > > In the absence of more code, we have to take the original poster's > word that callers to getSortedMap() actually depend on the insertion > order. But there's no reason to suppose they don't: the effects are in > no way limited to map creation. > Actually, he doesn't exactly say that /callers/ depend on insertion order. He said: > where I'm creating sortedMap above, I need the map to > retain the insertion order I interpret "where I'm creating the map" as being in the getSortedMap() method. Perhaps he really meant the code that calls getSortedMap(), in which case this method would be a factory method. But I assumed it wasn't, because of the getter-like name, and also because of what he said further below. If it were a factory method -- then yes, by all means. If it's a factory method that creates a map retaining insertion order, then its return type should be LinkedHashMap. But that's actually the only exception I can think of. I cannot fathom any other, normal OO case where LinkedHashMap would make sense as the type of a parameter to, or the return type of any method. -- DF. An escaped convict once said to me: "Alcatraz is the place to be"