Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED.shell.xmission.com!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Tue, 10 May 2011 13:15:41 -0600 Organization: As little as possible Message-ID: <2p62pimko2.fsf@shell.xmission.com> References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx01.eternal-september.org; posting-host="shell.xmission.com:2607:fa18:0:beef::4"; logging-data="26428"; mail-complaints-to="abuse@eternal-september.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:QxtDbYQK+w152YPKj/C+tL1SurQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3932 Michal Kleczek writes: > Arved Sandstrom wrote: > >> On 11-05-09 06:04 AM, Michal Kleczek wrote: >>> I think you are missing the fact that the client is _already_ tied to a >>> contract by calling getSortedMap() to get the map (since the contract of >>> getSortedMap() is "return a map implementation that provides such and >>> such iteration order". >>> The question is rather - do we need to specify this contract as a Java >>> type? I would rather say: since the compiler cannot enforce/check the >>> contract anyway then it is useless - the contract specified as >>> documentation of getSortedMap() is enough. >>> >> I agree that the compiler cannot enforce the contract unless both the >> provider of the LinkedHashMap and the calling code are written >> cooperatively to use LinkedHashMap explicitly, thereby locking in the >> requirement. This is the scenario I've been positing. >> >> As I believe I mentioned in another post, you could get away with >> documentation, but I believe you'd have to document not just the method, >> but also all the call sites. If you're going to rely on documentation >> then perhaps your biggest win would be to change the name of the method >> - getMap() would be an atrocious choice. IMO the only defensible choice is >> >> Map getPredictableIterationOrderMap() >> >> Now *this* stands out when you're using it. > > Sure - naming of functions is one of the most important aspects of defining > them. > Anyway. > Somehow I got lost in discussion and forgot the most important thing IMHO: > the fact that iteration order is important to the overall solution does not > imply it is important to the client code. Take an example: Agreed. Neither does it imply that it is *not* important. We don't have enough information to determine that one way or the other. -- Jim Janney