Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!goblin2!goblin.stu.neva.ru!plix.pl!newsfeed1.plix.pl!news.nask.pl!news.nask.org.pl!news.cyf-kr.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.POSTED!not-for-mail From: Michal Kleczek Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Mon, 09 May 2011 11:04:32 +0200 Organization: http://onet.pl Lines: 46 Message-ID: References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> NNTP-Posting-Host: 77-252-124-164.ip.netia.com.pl Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: news.onet.pl 1304931873 29589 77.252.124.164 (9 May 2011 09:04:33 GMT) X-Complaints-To: niusy@onet.pl NNTP-Posting-Date: Mon, 9 May 2011 09:04:33 +0000 (UTC) User-Agent: KNode/4.4.9 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3846 Arved Sandstrom wrote: > On 11-05-08 07:24 AM, Michal Kleczek wrote: >> Arved Sandstrom wrote: >> >>> Further note: behaviour isn't just a list of method signatures. It's >>> also what the abstract class or concrete class actually does. Not *how* >>> it does it - that's implementation - but what it does - that's >>> contractual _behaviour_. Keeping insertion order for iterators is >>> _behaviour_...using a doubly-linked list to accomplish that is >>> implementation. >> >> I think this is the real point of the discussion - Java interfaces are >> just too weak to express contracts. Note that there are many other >> aspects beside iteration ordering that are important to the overall >> solution but still not expressed (and not expressable) by interfaces: >> concurrency guarantees, performance and memory usage characteristics etc. >> Picking one aspect and trying to express it using Java types just does >> not make sense. > > Agreed, partly. It can't be done with Java interfaces at all. It can - > obviously - be done with the published API of abstract or concrete Java > classes. Then it would be not "what" but "how". > > What we're really arguing about here is whether it's desirable to bind > client code to provider contracts. It's clear that Map cannot enforce a > behavioural contract, and that LinkedHashMap does. Rather than beat that > to death, let's acknowledge that we have one camp that argues that we > don't want to tie the caller to a behavioural provider contract, and > another camp (me) that says that sometimes you do want and need to do > this. 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. -- Michal