aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes WOW Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "WOW" Watch "WOW" New topic
Author

WOW

Anton Rechenauer
Greenhorn

Joined: Dec 23, 2003
Posts: 13
all this exciting boohoo about

program to the interface, not the implementation

and some (most) examples contain a line like



WHY?


AR
Anton Rechenauer
Greenhorn

Joined: Dec 23, 2003
Posts: 13
oops, refered to Head First Design Patterns
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
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

Joined: Jan 29, 2003
Posts: 8791
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?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
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.


Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Anton Rechenauer
Greenhorn

Joined: Dec 23, 2003
Posts: 13



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

    Joined: Feb 02, 2002
    Posts: 1211

    You mean to say that I should write my methods like this -



    [ December 08, 2004: Message edited by: Sonny Gill ]

    The future is here. It's just not evenly distributed yet. - William Gibson
    Consultant @ Xebia. Sonny Gill Tweets
    Vladas Razas
    Ranch Hand

    Joined: Dec 02, 2003
    Posts: 385
    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

    Joined: Jul 11, 2001
    Posts: 14112
    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!


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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

    Joined: Dec 02, 2003
    Posts: 385
    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

    Joined: Dec 23, 2003
    Posts: 13
    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

    Joined: May 14, 2004
    Posts: 173
        
        6
    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


    Co-Author of Head First JavaScript Programming
    Anton Rechenauer
    Greenhorn

    Joined: Dec 23, 2003
    Posts: 13
    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

    Joined: Oct 14, 2004
    Posts: 94
    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

    Joined: May 14, 2004
    Posts: 173
        
        6

    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
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: WOW