Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Steven Simpson Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Fri, 06 May 2011 13:30:18 +0100 Organization: Aioe.org NNTP Server Lines: 47 Message-ID: References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <73jb98-ki2.ln1@news.simpsonst.f2s.com> NNTP-Posting-Host: LIxoCEaSvyCCWiRhZzh5EQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3677 On 05/05/11 23:29, Tom Anderson wrote: > On Thu, 5 May 2011, Steven Simpson wrote: >> Hypothetically, what you might want is an intermediate interface >> between Map and LinkedHashMap, e.g. InsertionOrderedMap, which >> extends Map but adds no methods. This might provide some sort of >> compile-time protection, that mere documentation cannot provide. >> >> However, IMHO, its value is dubious, for a few reasons: >> >> * An implementation of InsertionOrderedMap can be compiled without >> meeting the insertion-order requirement. >> * Another implementation of Map can be compiled without extending >> InsertionOrderedMap while meeting the insertion-order requirement. > > These points are true of any interface! Look: > > public class DubiousComparator implements Comparator { > public int compare(String a, String b) { > return 1; > } > } Yes, this has always bothered me about my argument. Perhaps I can refine it by noting that you could take any non-Set Collection implementation, extend it and declare it implementing Set without actually adding any extra methods. To make any class a Comparator, you will likely have to write an extra method, and deliberately write it wrongly. Oh, okay, it's not particularly robust (isn't upgrading a Collection implementation to a Set also deliberate?), but interfaces with no additional methods make me uneasy. > I feel Zapanaz's pain, but i think it's just One Of Those Things. Me too. Certainly, I would like to express these behavioural guarantees/constraints in a compiler-checkable way, but I don't think marker interfaces cut it. One reason is that behaviour may be instance-specific rather than class-specific (as seen with LinkedHashMap). Another is that guarantees may be dropped in subclasses (as WeakHashMap/IdentityHashMap do regarding Object.equals - is that wrong?). Yet another is that behaviours might be combined orthogonally, e.g. InsertionOrdered, NullKeys, NullValues, and you'd need to create an interface combining just those three - while using LinkedHashMap as the return type might offer more behaviours than you wish to promise. I'm resigned to leaving these issues as a matter of documentation.