Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.21.MISMATCH!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe22.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> <73jb98-ki2.ln1@news.simpsonst.f2s.com> <2p7ha4py6l.fsf@shell.xmission.com> In-Reply-To: <2p7ha4py6l.fsf@shell.xmission.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 62 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Thu, 05 May 2011 23:47:05 UTC Organization: Public Usenet Newsgroup Access Date: Thu, 05 May 2011 20:47:03 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3623 On 11-05-05 07:41 PM, Jim Janney wrote: > Steven Simpson writes: [ SNIP ] >> OTOH, this sort of thing is already done, with Set and Collection. Set >> extends Collection, but doesn't actually define any new methods. (It >> does take advantage of 'overriding' the documentation, though.) Is it >> worth having Set if: >> >> * you can implement Set without actually having set semantics? >> * you can implement set semantics with just Collection? >> >> So, if you're prepared to trust that an implementation of Set or >> InsertionOrderedMap follows the documented rules that can't be >> compiler-enforced, perhaps it's as well do away with those interfaces, >> and just put the documentation on methods like getSortedMap, and trust >> that they are implemented accordingly. > > That may be the best overall approach. The Javadoc for java.util.Map > explicitly notes that different implementations can provide different > behavior here. > Which is actually the case for a bunch of collections. Of relevance to this thread, LinkedHashMap provides 4 new method implementations, but 3 of them are overrides of methods in concrete class HashMap. Those 3 in turn are overrides of method implementations in AbstractMap. The two instantiable classes have different behaviour, though, so if I decide that it's really LinkedHashMap that I need, another Map will not do. So why refer to it as a Map? With Java collections, one may pass around a Map or a Set or a List, with reasonable trust that whatever is being shuttled around has high-level map/set/bag semantics, but many/most Java programmers also care a fair bit about the actual implementations used, because it matters. They behave differently. They may all be Maps or Sets or Lists, but they're not the same. It frequently is not acceptable to pass around just any Map or Set or List, so why is "program to the interface" so highly touted here? Beats me. My 2 cents worth. And I'm being a bit of non-conformist and shit disturber here. :-) And rather than rely only on documentation, what's wrong with using the language? I've picked ConcurrentHashMap, say, because I damned well need ConcurrentHashMap, and I want and require getAppropriateMap() to return a ConcurrentHashMap, so perhaps it is the proper thing to have getMap() return ConcurrentHashMap. Just a thought. I hearken back to your earlier observation, that: "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." This is absolutely true. And the Java Collections API is rife with possibilities for where "programming to the interface" is undesirable and counterproductive. AHS