Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

WOW

 
Anton Rechenauer
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
all this exciting boohoo about

program to the interface, not the implementation

and some (most) examples contain a line like



WHY?
 
Anton Rechenauer
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
oops, refered to Head First Design Patterns
 
Udayan Patel
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anton Rechenauer:
all this exciting boohoo about

program to the interface, not the implementation

and some (most) examples contain a line like



WHY?



And your point is?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interfaces let you talk in terms of promised capabilities instead of specific classes. Let's expand the ArrayList example a bit. Say I have a method:

You call it with an ArrayList of bank accounts and I can give you back the sum of their balances. One day you read up on collections and realize that a TreeSet would help you keep your bank accounts in alpha order by customer. You can't call my method with a TreeSet, only an ArrayList. Bummer.

What if my method had one tiny difference:

Collection promises that I can iterate the elements inside it, which is all I need to know. Now you and everybody else can call my method with any Collection best fit their needs. Sweet.

Moving beyond the java.util classes, say I accept a Product object and add a year to the warranty. If my method requires a Product interface you can send me a toaster, a blender, a TV, etc. What if we also warrantied service? Maybe we should make an UnderWarranty interface so you can pass me service events, too. Now I know nothing about the actual class being sent except that it promises to have some warranty-related methods.

In large systems we use this kind of abstraction to carefully control dependencies. For example, I don't want to update my warranty extender every time we add a product. If I own the UnderWarranty interface, nobody can change it, nobody else can break my code. Nice.

Zat help?
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess you are saying that the authors have given examples in the book of the form



and that you imply that they should be doing something like



I would say that the authors are justified as long as there is a method called



The whole point of the statement 'program to interfaces and not implementation' is to make the program provide an interface to the client that accesses the code and not an implementation. It doesn't matter how they instantiate it and use it locally.
 
Anton Rechenauer
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



is

  • very easy to understand
  • a good example for programming to the interface and easy to remember
  • IMHO good style, even if the variable l is local in a method or private in a class


  • therefore i would suggest to use it in introductory courses (and in Head First Books...)
     
    Sonny Gill
    Ranch Hand
    Posts: 1211
    IntelliJ IDE Mac
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You mean to say that I should write my methods like this -



    [ December 08, 2004: Message edited by: Sonny Gill ]
     
    Vladas Razas
    Ranch Hand
    Posts: 385
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    We could write also :





    I think it matters do we care about ArrayList abilities or not. I.e. if we need to call item(index) then we write:



    not



    When returning collection I usually build array when collection must not be modified. It's so much easier to work with arrays!
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Anton Rechenauer:



    is

  • very easy to understand

  • therefore i would suggest to use it in introductory courses (and in Head First Books...)

    Well, besides the "l" - I'd prefer a "list" here!
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Vladas Razas:
    I think it matters do we care about ArrayList abilities or not.


    Agreed!

    I.e. if we need to call item(index) then we write:



    not




    Huh, why that?
     
    Vladas Razas
    Ranch Hand
    Posts: 385
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sorry my mistake!


    Object get(int index)
    Returns the element at the specified position in this list.


    is in List interface not additional ArrayList feature. My example is wrong! But still in general i'd say idea is to take class/interface that is enough.

    About variable names I'd say it's wrong to derive variable name from type. I had a lot of cases when I changed lists into arrays. So the name "list" becomes incorrect. I name variables by their meaning. If I have list of elements I name it "elements", not "list". Of course this is harder to come by a good name. But there are exceptions, like factories. Usually their names perfectly good for variable names.
     
    Anton Rechenauer
    Greenhorn
    Posts: 13
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    therefore i would suggest to use it in introductory courses (and in Head First Books...), but if and only if you don't need anything from ArrayList later
     
    Elisabeth Robson
    author
    Ranch Hand
    Posts: 173
    6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    Interesting discussion.

    I agree in principle; however, in practice:

    1) We tried to keep the book examples *as simple as possible*. The fewer classes we have to explain the better. Not necessarily always a good excuse when we are violating our own principles, however.

    2) If we know that we will never need the ArrayList as a List, then it's not necessary.

    As stated in the book, the principles are guidelines. You don't have to use them in every single line of code. When the examples are simple, and we definitely need for a certain type (like Pizza) to be an interface, then that's a good place to illustrate the point. When we know for sure in our example programs we will never need ArrayList to be a List, then it's not necessary.

    We apply the principles when we think there's a chance that we might need to be flexible to change in the future. Many cases we use ArrayList knowing that we'll never (although one should never say never, right?) need it to be a List.

    But it's a good point, and perhaps we should make a point of pointing it out in the book, at least once ("point" three times in one sentence!! - four if you count this parentheses).

    Elisabeth
     
    Anton Rechenauer
    Greenhorn
    Posts: 13
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    my opinion: in practice it costs nothing - and one should always start as general as possible and "downcast" later (IFF it is necessary)

    for a beginner Collection lol = new ArrayList(); is an good "eye opener", something to think about; something strange

    should definitely mentioned in a head first book
     
    Udayan Patel
    Ranch Hand
    Posts: 94
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Anton Rechenauer:
    my opinion: in practice it costs nothing - and one should always start as general as possible and "downcast" later (IFF it is necessary)

    for a beginner Collection lol = new ArrayList(); is an good "eye opener", something to think about; something strange

    should definitely mentioned in a head first book


    I wouldn't do this!!! My idea of program to interface not implimentation is little different. I would take this principle for the API that I write and not the API other wrote. I would use third party API as it comes. Ah! that explains why ArrayList is an implementation if Collection and List but when we use it Why we do ArrayList list = new ArrayList(); oh well!!! welcome to the happy path (cult) of OO
     
    Elisabeth Robson
    author
    Ranch Hand
    Posts: 173
    6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    my opinion: in practice it costs nothing - and one should always start as general as possible and "downcast" later (IFF it is necessary)

    for a beginner Collection lol = new ArrayList(); is an good "eye opener", something to think about; something strange

    should definitely mentioned in a head first book


    One of our Head First Guidelines is this: we only have ONE point we try to get across at any one time (usually per page, often across several pages). The point of these chapters is the patterns and principles, not to teach Collections.

    Surprise is good, but not if it detracts from the point we are trying to get across, which is the pattern or principle. We can make the point about programming to an interface with Pizzas - we've introduced the pizza, the reader knows what a pizza is at this point. They may not know what a Collection is. So to introduce it here is to detract from the point of the page.

    I hope this makes sense. Your points are good, but they have to be considered carefully.

    Elisabeth
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic