Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #3578 > unrolled thread

"Program to an interface" - When to break a design pattern

Back to article view | Back to comp.lang.java.programmer

Contents

  "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 12:21 -0700
    Re: "Program to an interface" - When to break a design pattern Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-05 15:43 -0400
      Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:19 -0400
    Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 21:47 +0200
    Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 14:14 -0600
      Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 13:26 -0700
      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 22:27 +0200
        Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 14:42 -0600
          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 22:48 +0200
            Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 15:02 -0600
              Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 00:02 +0200
                Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 19:49 -0300
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 02:28 +0200
                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 07:24 -0300
                      Re: "Program to an interface" - When to break a design pattern Patricia Shanahan <pats@acm.org> - 2011-05-06 07:03 -0700
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 17:30 -0300
                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 18:56 +0200
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 17:50 -0300
                          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 23:37 +0200
                            Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 19:43 -0300
                Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 17:17 -0600
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 02:28 +0200
            Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 23:25 -0700
              Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 18:25 +0200
                Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-07 16:26 -0700
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 03:28 +0200
                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 00:05 -0300
                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 16:15 +0200
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 14:20 -0300
                          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 19:48 +0200
                            Re: "Program to an interface" - When to break a design pattern markspace <-@.> - 2011-05-10 07:36 -0700
                              Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-10 13:04 -0600
                                Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-10 21:31 +0200
                              Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-10 20:01 -0300
                                Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 19:14 +0200
                                Re: "Program to an interface" - When to break a design pattern Patricia Shanahan <pats@acm.org> - 2011-05-11 10:41 -0700
                                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 19:55 +0200
                                    Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-11 16:42 -0400
                                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 23:34 +0200
                                        Re: "Program to an interface" - When to break a design pattern "John B. Matthews" <nospam@nospam.invalid> - 2011-05-12 00:51 -0400
                                          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-12 00:58 -0400
                                            Re: "Program to an interface" - When to break a design pattern Tom Anderson <twic@urchin.earth.li> - 2011-05-12 20:08 +0100
                                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-15 13:25 -0300
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:24 -0400
            Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 16:00 -0600
            Re: "Program to an interface" - When to break a design pattern Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-05-06 15:01 +0300
              Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 12:17 -0400
                Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-07 16:28 -0700
      Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:21 -0400
        Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 15:58 -0600
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 18:18 -0400
        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 19:20 -0300
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 18:23 -0400
            Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 20:17 -0300
    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 18:26 -0300
    Re: "Program to an interface" - When to break a design pattern Steven Simpson <ss@domain.invalid> - 2011-05-05 22:57 +0100
      Re: "Program to an interface" - When to break a design pattern Tom Anderson <twic@urchin.earth.li> - 2011-05-05 23:29 +0100
        Re: "Program to an interface" - When to break a design pattern Steven Simpson <ss@domain.invalid> - 2011-05-06 13:30 +0100
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 12:19 -0400
      Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 16:41 -0600
        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 20:47 -0300
    Re: "Program to an interface" - When to break a design pattern Roedy Green <see_website@mindprod.com.invalid> - 2011-05-05 16:41 -0700
      Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 22:47 -0600
      Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 23:28 -0700
    Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-06 17:15 +0200
      Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 20:53 -0300
        Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 21:39 -0400
          Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-07 00:56 -0300
        Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-08 12:24 +0200
          Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 13:42 -0300
            Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-09 11:04 +0200
              Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-09 19:33 -0300
                Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-10 15:51 +0200
                  Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-10 13:15 -0600
                  Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-10 19:40 -0300

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#4001

On 05/12/2011 12:51 AM, John B. Matthews wrote:
> In article<iqevca$fmg$1@dont-email.me>,
>   Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>  wrote:
>
>> On 11/05/2011 22:42, Lew allegedly wrote:
>>> Daniele Futtorovic wrote:
>>>> Patricia Shanahan allegedly wrote:
>>>>> I think some of the trouble might lie in the ambiguity, in a Java
>>>>> context, of the sentence "Program to an interface.".
>>>>>
>>>>> Meaning 1: Users of some module (in the widest sense) should
>>>>> depend only on what is declared and specified about the module,
>>>>> not on direct knowledge of how it is currently implemented.
>>>>>
>>>>> Meaning 2: Java programs should depend only in Java interface
>>>>> types to represent what is declared and specified about a module
>>>>> for the use of its callers.
>>>>>
>>>>> I am very strongly in favor of meaning 1 of "Program to an
>>>>> interface.". Everything any user of a module needs to know about
>>>>> it should be declared and/or specified as part of its interface
>>>>> (in the general sense), and using code should depend only on what
>>>>> is declared and specified.
>>>
>>>> Absolutely. Isn't the wording "program to a contract rather to an
>>>> implementation" also in use? I find that a much better one,
>>>> because it doesn't evoke Java interfaces.
>>>
>>> I like the notion "program to the type". This subsumes Java
>>> interfaces and classes, allows intelligent use of generics (which
>>> augment Java interfaces just beautifully) to make type assertions,
>>> and incorporates the notion of programming to a contract. It also
>>> allows the type to be 'LinkedHashMap' where that is the type whose
>>> contract you actually need.
>>
>> Not sure about "type". To me this "to the interface/contract" is a
>> step on the path towards hypothetical minimalism and good
>> definitions. Good definitions are a Good Thing not only for types,
>> but also for components, layers and applications as a whole. But
>> they're different /sorts/ of definitions for each level.
>>
>>> I have run into serious pushback from people who have a religion
>>> about contract-based programming and a very different idea from me
>>> about who should enforce what parts of a given contract. I don't
>>> remember which Received-From-On-High placebo, er, miracle language
>>> they were touting - it's famous but I don't care so I forget - that
>>> allowed them to be just as dogmatic about "contract" as some in
>>> Java are about "interface", but their flavor of fundamentalism was
>>> no improvement. One One True Way's proselyte is just as crappy and
>>> obnoxious as every other One True Way's.
>>
>> _Ada_, mayhap?
>
> Ada [1]? It's not impossible, but the zealotry reminds me more of
> Eiffel [2], which includes particular support for design by contract
> [3]. Lew's notion of "program to the type" reminds me of the concept of
> abstract data type [4], which is well supported by Ada's notion of
> specification (package interface) and consistent with Patricia's
> Meaning 1.
>
> [1]<http://en.wikipedia.org/wiki/Ada_(programming_language)>
> [2]<http://en.wikipedia.org/wiki/Eiffel_(programming_language)#Design_by_Contract>
> [3]<http://en.wikipedia.org/wiki/Eiffel_(programming_language)#Design_by_Contract>
> [4]<http://en.wikipedia.org/wiki/Abstract_data_type>

Yeah, it was Eiffel.  Oy.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#4015

On Thu, 12 May 2011, Lew wrote:

> On 05/12/2011 12:51 AM, John B. Matthews wrote:
>> In article<iqevca$fmg$1@dont-email.me>,
>>   Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>  wrote:
>> 
>>> On 11/05/2011 22:42, Lew allegedly wrote:
>>>
>>>> I have run into serious pushback from people who have a religion 
>>>> about contract-based programming and a very different idea from me 
>>>> about who should enforce what parts of a given contract. I don't 
>>>> remember which Received-From-On-High placebo, er, miracle language 
>>>> they were touting - it's famous but I don't care so I forget - that 
>>>> allowed them to be just as dogmatic about "contract" as some in Java 
>>>> are about "interface", but their flavor of fundamentalism was no 
>>>> improvement. One One True Way's proselyte is just as crappy and 
>>>> obnoxious as every other One True Way's.
>>> 
>>> _Ada_, mayhap?
>> 
>> Ada [1]? It's not impossible, but the zealotry reminds me more of 
>> Eiffel [2], which includes particular support for design by contract
>
> Yeah, it was Eiffel.  Oy.

Are you thinking of the Eiffel fanboy who came round here with his little 
toy language and made trouble? Few years back. I got in a scrap with him. 
The guy was technically mistaken, which is fine, but he was also an 
arrogant prat, which is not.

tom

-- 
only positivistic reason and the forms of philosophy based on it are
universally valid -- Pope Benedict XVI

[toc] | [prev] | [next] | [standalone]

#4126

On 11-05-11 02:55 PM, Daniele Futtorovic wrote:
> On 11/05/2011 19:41, Patricia Shanahan allegedly wrote:
>> I think some of the trouble might lie in the ambiguity, in a Java
>> context, of the sentence "Program to an interface.".
>>
>> Meaning 1: Users of some module (in the widest sense) should depend only
>> on what is declared and specified about the module, not on direct
>> knowledge of how it is currently implemented.
>>
>> Meaning 2: Java programs should depend only in Java interface types to
>> represent what is declared and specified about a module for the use of
>> its callers.
>>
>> I am very strongly in favor of meaning 1 of "Program to an interface.".
>> Everything any user of a module needs to know about it should be
>> declared and/or specified as part of its interface (in the general
>> sense), and using code should depend only on what is declared and
>> specified.
> 
> Absolutely. Isn't the wording "program to a contract rather to an
> implementation" also in use? I find that a much better one, because it
> doesn't evoke Java interfaces.
> 
Fervent agreement. Especially if we're talking about OOP languages that
actually have "interface" constructs.

The first time I had this concept introduced to me, "program to an
interface", I hadn't even started using Java because only about a dozen
people at Sun were using Java. :-) So "interface" to me means "contract".

In fact it was a bit of a surprise to me when I discovered, in the
course of doing intensive research during this thread, that many Java
eminences really do mean "Java interface" specifically when they
advocate "program to an interface". This is quite a strong principle -
stronger (or, shall we say, more selective) than the general one.

AHS

[toc] | [prev] | [next] | [standalone]

#3600

Jim Janney wrote:
> The justification is not in the code shown, but in the accompanying
> remark "I need the map to retain the insertion order."  There's no
> interface in the JRE that promises this,

other than
<http://download.oracle.com/javase/6/docs/api/java/util/SortedMap.html>
you mean.

> and only one class that provides it, which makes encapsulation, shall we say, difficult.

Oh, really?

Two are listed in the API docs for that "nonexistent" interface, and neither 
one is 'LinkedHashMap'.

Knowing the collections API is a prerequisite for effective Java programming.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3607

Lew <noone@lewscanon.com> writes:

> Jim Janney wrote:
>> The justification is not in the code shown, but in the accompanying
>> remark "I need the map to retain the insertion order."  There's no
>> interface in the JRE that promises this,
>
> other than
> <http://download.oracle.com/javase/6/docs/api/java/util/SortedMap.html>
> you mean.
>
>> and only one class that provides it, which makes encapsulation, shall we say, difficult.
>
> Oh, really?
>
> Two are listed in the API docs for that "nonexistent" interface, and
> neither one is 'LinkedHashMap'.
>
> Knowing the collections API is a prerequisite for effective Java programming.

The original poster said very plainly, "I need the map to retain the
insertion order."  A SortedMap does not do this.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#3675

Lew <noone@lewscanon.com> writes:
> Jim Janney wrote:
>> The justification is not in the code shown, but in the accompanying
>> remark "I need the map to retain the insertion order."  There's no
>> interface in the JRE that promises this,

> other than
> <http://download.oracle.com/javase/6/docs/api/java/util/SortedMap.html>
> you mean.

But I'm looking at the SortedMap and LinkedHashMap javadocs, and it
seems to me that LinkedHashMap doesn't implement the SortedMap
interface. 
So, defining the return value as SortedMap you'd have to change the
actual implementation class.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#3695

On 05/06/2011 08:01 AM, Jukka Lahtinen wrote:
> Lew<noone@lewscanon.com>  writes:
>> Jim Janney wrote:
>>> The justification is not in the code shown, but in the accompanying
>>> remark "I need the map to retain the insertion order."  There's no
>>> interface in the JRE that promises this,
>
>> other than
>> <http://download.oracle.com/javase/6/docs/api/java/util/SortedMap.html>
>> you mean.
>
> But I'm looking at the SortedMap and LinkedHashMap javadocs, and it
> seems to me that LinkedHashMap doesn't implement the SortedMap
> interface.
> So, defining the return value as SortedMap you'd have to change the
> actual implementation class.

Yes, noted multiple times so far.  I was wrong.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3772

On Fri, 06 May 2011 12:17:55 -0400, Lew <noone@lewscanon.com> wrote:

>On 05/06/2011 08:01 AM, Jukka Lahtinen wrote:
>> Lew<noone@lewscanon.com>  writes:
>>> Jim Janney wrote:
>>>> The justification is not in the code shown, but in the accompanying
>>>> remark "I need the map to retain the insertion order."  There's no
>>>> interface in the JRE that promises this,
>>
>>> other than
>>> <http://download.oracle.com/javase/6/docs/api/java/util/SortedMap.html>
>>> you mean.
>>
>> But I'm looking at the SortedMap and LinkedHashMap javadocs, and it
>> seems to me that LinkedHashMap doesn't implement the SortedMap
>> interface.
>> So, defining the return value as SortedMap you'd have to change the
>> actual implementation class.
>
>Yes, noted multiple times so far.  I was wrong.

My method name was unfortunate.
-- 
Zapanaz
International Satanic Conspiracy
Customer Support Specialist
http://joecosby.com/ 
You know you're in Saskatchewan when you can sit on your front porch 
and watch your dog run away for three days

:: Currently listening to Todesfuge, 2003, by Diamanda Galás, from "Defixiones, Will and Testament"

[toc] | [prev] | [next] | [standalone]

#3599

On 05/05/2011 04:14 PM, Jim Janney wrote:
> Zapanaz<http://joecosby.com/code/mail.pl@foo.com>  writes:
>
>> I've seen this design pattern before
>>
>> http://witte-consulting.com/documents/design-principles/
>>
>> and, in general, I see the point of it.
>>
>> But say we've got something like this
>>
>> LinkedHashMap<String, Integer>  sortedMap = this.getSortedMap();
>>
>> So you have the method
>>
>> public LinkedHashMap<String, Integer>  getSortedMap() {
>>    //do stuff
>> }
>>
>> (not necessarily public)
>>
>> Now the design principle says, the method signature should instead be
>>
>> public Map<String, Integer>  getSortedMap() {
>>    //do stuff
>> }
>>
>> The problem is, where I'm creating sortedMap above, I need the map to
>> retain the insertion order. If what's returned actually is a Map,
>> rather than a LinkedHashMap, then the results the user actually sees
>> are going to be in the wrong order. Making things worse, in this case,
>> nothing would actually break, only the end user would notice anything
>> was actually wrong.
>>
>> So in this case, it seems to me, that using LinkedHashMap in the
>> method signature makes sense. The fact that the return retains the
>> insertion order is an integral part of what the method does.
>>
>> If nothing else, it's going to save Fred Developer down the line from
>> looking at the code around this
>>
>> Map<String, Integer>  sortedMap = this.getSortedMap();
>>
>> and thinking "wait, how do I know getSortedMap() is going to return a
>> result with the right ordering?", and having to waste time digging
>> into that method.

'SortedMap', as so many have said.  Apparently you need to practice study of 
the API docs much, much more.  We all should know the essential collections 
types.  Get studying!

> 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.  So in this case, no,
> programming to the interface would be the wrong thing to do.  The point
> of design principles is to make you think before you break them :-)

Actually, in this case programming to the interface is the /right/ thing to 
do.  Please don't mislead the OP.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3605

Lew <noone@lewscanon.com> writes:

> On 05/05/2011 04:14 PM, Jim Janney wrote:
>> Zapanaz<http://joecosby.com/code/mail.pl@foo.com>  writes:
>>
>>> I've seen this design pattern before
>>>
>>> http://witte-consulting.com/documents/design-principles/
>>>
>>> and, in general, I see the point of it.
>>>
>>> But say we've got something like this
>>>
>>> LinkedHashMap<String, Integer>  sortedMap = this.getSortedMap();
>>>
>>> So you have the method
>>>
>>> public LinkedHashMap<String, Integer>  getSortedMap() {
>>>    //do stuff
>>> }
>>>
>>> (not necessarily public)
>>>
>>> Now the design principle says, the method signature should instead be
>>>
>>> public Map<String, Integer>  getSortedMap() {
>>>    //do stuff
>>> }
>>>
>>> The problem is, where I'm creating sortedMap above, I need the map to
>>> retain the insertion order. If what's returned actually is a Map,
>>> rather than a LinkedHashMap, then the results the user actually sees
>>> are going to be in the wrong order. Making things worse, in this case,
>>> nothing would actually break, only the end user would notice anything
>>> was actually wrong.
>>>
>>> So in this case, it seems to me, that using LinkedHashMap in the
>>> method signature makes sense. The fact that the return retains the
>>> insertion order is an integral part of what the method does.
>>>
>>> If nothing else, it's going to save Fred Developer down the line from
>>> looking at the code around this
>>>
>>> Map<String, Integer>  sortedMap = this.getSortedMap();
>>>
>>> and thinking "wait, how do I know getSortedMap() is going to return a
>>> result with the right ordering?", and having to waste time digging
>>> into that method.
>
> 'SortedMap', as so many have said.  Apparently you need to practice
> study of the API docs much, much more.  We all should know the
> essential collections types.  Get studying!

But that would be wrong, because a SortedMap does something entirely
different from a LinkedHashMap.  Take your own advice before dispensing
it to others.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#3610

Jim Janney wrote:
> But that would be wrong, because a SortedMap does something entirely
> different from a LinkedHashMap.  Take your own advice before dispensing
> it to others.

It's a fair cop.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3612

On 11-05-05 06:21 PM, Lew wrote:
> On 05/05/2011 04:14 PM, Jim Janney wrote:
[ SNIP ]

>> 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.  So in this case, no,
>> programming to the interface would be the wrong thing to do.  The point
>> of design principles is to make you think before you break them :-)
> 
> Actually, in this case programming to the interface is the /right/ thing
> to do.  Please don't mislead the OP.
> 
Well, no. The OP has stated that he needs the map to obey the contract
of LinkedHashMap: "where I'm creating sortedMap above, I need the map to
retain the insertion order". This is the normal behaviour of
LinkedHashMap, that its predictable iteration ordering is
insertion-order. If he wants a map that has this iterator ordering, he
wants LinkedHashMap (and possibly no other maps qualify actually; I am
not 100% certain on this).

It would be a mistake for the OP to write an API method that returns a
Map when just any Map won't pass muster. It's not that _his_ method
won't do the right thing, but that the client code that gets a Map will
be written to Map, and eventually at some point some other Map
implementation will get used instead.

As it happens this example highlights one main thing that interfaces
don't do, which is to prescribe implementation contracts. Classes do
that; interfaces can't. And in this particular case there is not even an
available superclass that also satisfies the implementation contracts.
So LinkedHashMap is appropriate.

AHS

[toc] | [prev] | [next] | [standalone]

#3613

Arved Sandstrom wrote:
> Lew wrote:
>> Actually, in this case programming to the interface is the /right/ thing
>> to do.  Please don't mislead the OP.
>>
> Well, no. The OP has stated that he needs the map to obey the contract
> of LinkedHashMap: "where I'm creating sortedMap above, I need the map to
> retain the insertion order". This is the normal behaviour of
> LinkedHashMap, that its predictable iteration ordering is
> insertion-order. If he wants a map that has this iterator ordering, he
> wants LinkedHashMap (and possibly no other maps qualify actually; I am
> not 100% certain on this).

Yes, Jim Janney already corrected me on this.

Mea culpa.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3620

On 11-05-05 07:23 PM, Lew wrote:
> Arved Sandstrom wrote:
>> Lew wrote:
>>> Actually, in this case programming to the interface is the /right/ thing
>>> to do.  Please don't mislead the OP.
>>>
>> Well, no. The OP has stated that he needs the map to obey the contract
>> of LinkedHashMap: "where I'm creating sortedMap above, I need the map to
>> retain the insertion order". This is the normal behaviour of
>> LinkedHashMap, that its predictable iteration ordering is
>> insertion-order. If he wants a map that has this iterator ordering, he
>> wants LinkedHashMap (and possibly no other maps qualify actually; I am
>> not 100% certain on this).
> 
> Yes, Jim Janney already corrected me on this.
> 
> Mea culpa.
> 
Having had "program to the interface" pounded into my head so
thoroughly, I was originally going to set the OP straight myself. :-)
But then in the course of researching the API Javadocs and re-reading
the original post, I twigged to that detail.

Like I said prior, there is a large area of contracts that cannot be
specified simply with interfaces. I misspoke when I suggested that it's
only implementation contracts that interfaces can't handle; in fact this
"predictable iteration order" is also a behavioural contract that
interfaces cannot specify. When all is said and done, all that
interfaces can do in Java is prescribe a group of method signatures.

Some languages permit more expressibility when composing implementation
(Scala traits, for example), but ultimately what interfaces don't give
you in Java, abstract classes do (or in very specific cases like this
one, one actual concrete class). I _like_ abstract classes; I think the
pendulum has swung too far now in the "program to interfaces" direction.
Back in the day inheritance was all the rage; post-GOF it became
(rightfully so) a somewhat deprecated thing to do, but IMHO there is no
good reasopn to eschew abstract classes completely.

In this specific case we have run across the common circumstance where
only one class fits the bill. And so we may as well use it. :-)

AHS

[toc] | [prev] | [next] | [standalone]

#3601

On 11-05-05 04:21 PM, Zapanaz wrote:
> 
> I've seen this design pattern before
> 
> http://witte-consulting.com/documents/design-principles/
> 
> and, in general, I see the point of it.
> 
> But say we've got something like this
> 
> LinkedHashMap<String, Integer> sortedMap = this.getSortedMap();

Except it's not sorted. It has "predictable iteration order", but it's
not sorted.
> 
> So you have the method
> 
> public LinkedHashMap<String, Integer> getSortedMap() {
>   //do stuff
> }
> 
> (not necessarily public)
> 
> Now the design principle says, the method signature should instead be
> 
> public Map<String, Integer> getSortedMap() {
>   //do stuff
> }

That design principle is "program to an interface" (i.e. to behaviour
rather than implementation), and it's a good _general_ idea.

Specifically, the design principle means that you return something of
the most general type *that satisfies client requirements*. An
applicable rule of thumb is that you return what all (or nearly all) of
the calling code can use without downcasting, which is generally an
ungood thing to do. A related rule is that client requirements include
contracts, which in this case has to do with the predictable iteration
ordering of LinkedHashMap - Map does not have that.

> The problem is, where I'm creating sortedMap above, I need the map to
> retain the insertion order. If what's returned actually is a Map,
> rather than a LinkedHashMap, then the results the user actually sees
> are going to be in the wrong order. Making things worse, in this case,
> nothing would actually break, only the end user would notice anything
> was actually wrong.

No, this is _not_ one of the problems at hand. If you constructed a
LinkedHashMap then that instance will remain a LinkedHashMap regardless
of whether you return it as a Map or a HashMap or an AbstractMap. Or
even a Cloneable.

> So in this case, it seems to me, that using LinkedHashMap in the
> method signature makes sense. The fact that the return retains the
> insertion order is an integral part of what the method does.

In this particular case I'd return LinkedHashMap also. That's what you
need. The danger of returning a Map is that client code will be written
against Map, and in theory any implementation of that very high-level
interface can be substituted.

> If nothing else, it's going to save Fred Developer down the line from
> looking at the code around this
> 
> Map<String, Integer> sortedMap = this.getSortedMap();
> 
> and thinking "wait, how do I know getSortedMap() is going to return a
> result with the right ordering?", and having to waste time digging
> into that method.

As I alluded to above, I'd make Fred's life easier by not referring to
it as a sorted map. The method signature

public LinkedHashMap<K, V> getMap()

adequately documents things for Fred, and doesn't make the mistake of
implying sorting.

As Jim Janney mentioned, don't program to an interface if it's that
specific implementation that you must have.

AHS

[toc] | [prev] | [next] | [standalone]

#3606

On 05/05/11 20:21, Zapanaz wrote:
> So you have the method
>
> public LinkedHashMap<String, Integer> getSortedMap() {
>   //do stuff
> }
>
> (not necessarily public)
>
> Now the design principle says, the method signature should instead be
>
> public Map<String, Integer> getSortedMap() {
>   //do stuff
> }
>
> The problem is, where I'm creating sortedMap above, I need the map to
> retain the insertion order. If what's returned actually is a Map,
> rather than a LinkedHashMap,

(I'll assume that you meant "If what's returned is not an implementation
of LinkedHashMap...", rather than addressing the literal point.)

>  then the results the user actually sees
> are going to be in the wrong order. Making things worse, in this case,
> nothing would actually break, only the end user would notice anything
> was actually wrong.
>
> So in this case, it seems to me, that using LinkedHashMap in the
> method signature makes sense. The fact that the return retains the
> insertion order is an integral part of what the method does.

I would say that it was still better just to use Map, as LinkedHashMap
need not be the only implementation with the predictable iteration that
the caller expects.  Additional documentation is then required, of course.

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.
    * Specifically for LinkedHashMap, it can actually provide access
      order instead, so it couldn't implement both InsertionOrderedMap
      and a similar AccessOrderedMap without breaking at least one
      requirement, whichever way a particular instance was configured.

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.

[toc] | [prev] | [next] | [standalone]

#3615

On Thu, 5 May 2011, Steven Simpson wrote:

> On 05/05/11 20:21, Zapanaz wrote:
>
>> So in this case, it seems to me, that using LinkedHashMap in the method 
>> signature makes sense. The fact that the return retains the insertion 
>> order is an integral part of what the method does.
>
> 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<String> {
 	public int compare(String a, String b) {
 		return 1;
 	}
}

public class NotAComparator /* does not implement Comparator<String> */ {
 	public int compare(String a, String b) {
 		return a.compareTo(b);
 	}
}

Interfaces are useful because they let you make a promise; alas, making 
programmers keep their promises is beyond any compiler.

>    * Specifically for LinkedHashMap, it can actually provide access
>      order instead, so it couldn't implement both InsertionOrderedMap
>      and a similar AccessOrderedMap without breaking at least one
>      requirement, whichever way a particular instance was configured.

I think it would be sufficient to have an interface OrderedMap, which is, 
very roughly, to a Map what a List is to a Set. Except really, we would 
also want an OrderedSet. SortedMap/Set could perhaps be a subtype of 
OrderedMap/Set; or, borrowing from Smalltalk, we could have a 
SequenceableMap/Set, from which we derive different kinds of sequencing. I 
think these things would be useful, but not enormously so. I feel 
Zapanaz's pain, but i think it's just One Of Those Things.

tom

-- 
Men? Women? Give me a colossal death robot any day!

[toc] | [prev] | [next] | [standalone]

#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<String> {
>     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.

[toc] | [prev] | [next] | [standalone]

#3696

Steven Simpson wrote:
> 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.

This sounds like a use case for annotations.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3617

Steven Simpson <ss@domain.invalid> writes:

> On 05/05/11 20:21, Zapanaz wrote:
>> So you have the method
>>
>> public LinkedHashMap<String, Integer> getSortedMap() {
>>   //do stuff
>> }
>>
>> (not necessarily public)
>>
>> Now the design principle says, the method signature should instead be
>>
>> public Map<String, Integer> getSortedMap() {
>>   //do stuff
>> }
>>
>> The problem is, where I'm creating sortedMap above, I need the map to
>> retain the insertion order. If what's returned actually is a Map,
>> rather than a LinkedHashMap,
>
> (I'll assume that you meant "If what's returned is not an implementation
> of LinkedHashMap...", rather than addressing the literal point.)
>
>>  then the results the user actually sees
>> are going to be in the wrong order. Making things worse, in this case,
>> nothing would actually break, only the end user would notice anything
>> was actually wrong.
>>
>> So in this case, it seems to me, that using LinkedHashMap in the
>> method signature makes sense. The fact that the return retains the
>> insertion order is an integral part of what the method does.
>
> I would say that it was still better just to use Map, as LinkedHashMap
> need not be the only implementation with the predictable iteration that
> the caller expects.  Additional documentation is then required, of course.

Good point.  It turns out there's a LinkedMap in Apache Commons that
also does this.

> 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.
>     * Specifically for LinkedHashMap, it can actually provide access
>       order instead, so it couldn't implement both InsertionOrderedMap
>       and a similar AccessOrderedMap without breaking at least one
>       requirement, whichever way a particular instance was configured.
>
> 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.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web