Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!news.glorb.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe02.iad.POSTED!8ad76e89!not-for-mail
From: Arved Sandstrom <asandstrom3minus1@eastlink.ca>
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> <iq139v$feg$1@news.onet.pl> <GR%wp.68076$yp3.20908@newsfe09.iad> <iq5r0f$il6$1@news.onet.pl> <JJzxp.21021$uh5.14366@newsfe02.iad> <iq8an1$ssl$1@news.onet.pl> <sZZxp.15218$Du7.4644@newsfe04.iad> <iqbfs5$3u7$1@news.onet.pl>
In-Reply-To: <iqbfs5$3u7$1@news.onet.pl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Lines: 82
Message-ID: <K9jyp.25$RT2.19@newsfe02.iad>
X-Complaints-To: abuse@newsgroups-download.com
NNTP-Posting-Date: Tue, 10 May 2011 22:40:42 UTC
Organization: Public Usenet Newsgroup Access
Date: Tue, 10 May 2011 19:40:41 -0300
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3939

On 11-05-10 10:51 AM, Michal Kleczek wrote:
> 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:
> 
> //the program is supposed to print hashcodes of strings provided as
> //arguments in the order that the user gave them
> //forget that the map is not needed here
> public void PrintHashes {
> 
>   public static void main(String[] args) {
>     final Map<String, Integer> mapOfHashes = new LinkedHashMap<>();
>     calculateHashes(Arrays.asList(args), mapOfHashes);
>     printMap(mapOfHashes, System.out);
>   }
> 
>   private static <T> void calculateHashes(
>     Iterable<? extends T> objects,
>     Map<? super T, ? super Integer> hashes) {
>     for (final Object object : objects) {
>       hashes.put(object, object.hashCode());
>     }
>   }
> 
>   private static void printMap(Map<?, ?> map, PrintStream out) {
>     for (final Map.Entry<?, ?> entry : map.entrySet()) {
>       out.println("Key: " + entry.getKey() + " Value: " + entry.getValue());
>     }
>   }
> 
> }
> 
> According to your logic all references to Map<whatever> should be replaced 
> by LinkedHashMap<String, Integer> which - sorry to say that - sounds insane 
> :)

_That_ is not _my_ logic. My logic is that in the example provided by
the OP, there are sets of circumstances that make explicit use of
LinkedHashMap reasonable. These sets of circumstances may include both
the providing and calling code being non-published (that is, both of
them are involved in implementation details), and also the desire of the
designer/implementer to absolutely lock in this choice of Map
implementation in that non-published code.

Fact is, we don't know how public/published the OP intends that
map-producing method to be. Since we don't know, I've repeatedly tried
to more clearly explain the specific circumstances where I believe that
not using Map won't offend against the "program to the interface"
religion. I'm getting that there is quite a large group out there that
doesn't countenance *ever* breaking "program to the interface". So be it.

AHS