Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!news.glorb.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe04.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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Lines: 62 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Sat, 07 May 2011 03:56:20 UTC Organization: Public Usenet Newsgroup Access Date: Sat, 07 May 2011 00:56:19 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3743 On 11-05-06 10:39 PM, Lew wrote: > On 05/06/2011 07:53 PM, Arved Sandstrom wrote: [ SNIP ] > Here are the relevant chapter titles from /Effective Java/, by Joshua > Bloch: > Item 18: Prefer interfaces to abstract classes > Item 19: Use interfaces only to define types > Item 52: Refer to objects by their interfaces > Item 53: Prefer interfaces to reflection > > Here he refers to the Java 'interface', not the more general term you > just discussed. > > Note that in the details of Item 52, Mr. Bloch covers using the more > specific types when the contract (the GoF sense of "interface") calls > for it: > > "If appropriate interface types exist, then ... your program will be > more flexible if you use the interface to refer to the object; if not, > just use the least specific class in the class hierarchy that provides > the required functionality." Fair enough. As far as Item 52 goes, I think that's what everyone is saying, given that elaboration you quoted. Item 19, no argument from me. Item 53, I won't argue about that either. Item 18, "prefer interfaces to abstract classes" is a short & sweet recommendation that more often than not is a good one to follow. Particularly in Java, where language limitations, as Bloch himself points out, seriously limit the use of abstract classes as type definitions. However, the use of the word "prefer" means to me that available interfaces are used over available abstract classes when consideration shows that it's the best choice, not just because a single-sentence principle says so. One important thing needs to be pointed out here, and it's mentioned in Item 18 by Bloch: " Any class that defines all of the required methods and obeys the general contract is permitted to implement an interface". The sticking point in this thread is the _general contract_ - there is no interface, Map or otherwise, that has the contract required by the OP. Short of defining a PredictableIterationOrderMap interface and having a subclass of LinkedHashMap implement that, one may as well use LinkedHashMap. Per Bloch's Item 52 - there is no appropriate interface type available here. To rephrase that, we should be choosing types - interfaces, abstract classes, or concrete classes - whose contracts match the requirements. And a bag of method signatures is not a contract (except between the code and the compiler). Behaviour specified in the API Javadocs (in the case of maps, starting right with java.util.Map) is the actual contract. The practise of using a Java interface at all costs, and the most general interface at that, with little or no attention paid to the fact that the general type you are passing around does not have a required contract, is so prevalent in the industry that these days, if you try to point out the intent of the design principle, people often have no clue what you are trying to express. It's a losing battle. There's certainly no shortage of folks who think that that "bag of method signatures" _is_ the contract, that's for sure. AHS