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: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Thu, 05 May 2011 17:17:41 -0600 Organization: As little as possible Lines: 47 Message-ID: <2py62kohyi.fsf@shell.xmission.com> References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <2psjssq4zj.fsf@shell.xmission.com> <2poc3gq3p2.fsf@shell.xmission.com> <2pk4e4q2sq.fsf@shell.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="dZdavj/jUDynNQgDq5jkeA"; logging-data="25061"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1981SsFpoG1Fwd0g9pqJCki" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ic2NRKeF0ITNIZRX4tgzt/XltJk= sha1:Q3nR3Zn4r+K5dTzQnw31D/D6/tY= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3621 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. -- Jim Janney