• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why we return type Mostly Interface rather than Class?

 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HI friends
We preferably return an interface rather than a class.
Suppose like if we have to return a ArrayList from a method, we declare return type as Collection or List. Why we use like this.
Is this a Design issue or something else?
Can any body explain ?
Thanks in-advance
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The benefit is that returning an interface makes it possible to change the implementation later on. E.g., you might decide after a while that you'd much rather use a LinkedList instead of an ArrayList. If the return type is "ArrayList", you're out of luck - all code that depends on it must be recompiled (and possibly rewritten if it makes use of ArrayList features that are not part of List). Had you declared the return type to be List, you could simply return a LinkedList instead.

Most of the time it is sufficient to know that the type will be a List (or Map), without the need to use other features of the implementing classes.
 
Ranch Hand
Posts: 360
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I usually explain the difference between class-approach and interface-approach by emphasising the dependency. Interface-approach results in low dependency, which is usually called low (or loose) coupling, whereas class-approach results in the opposite.
 
Ranch Hand
Posts: 457
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is usually no functionality on a particular collection implementation that you need to access outside of the generic interface.

As an example, it may be the case that after writing your code you find out that it often happens that you delete the first item of a 1000s long list. If you used an implementation that causes all of the other elements to be "moved", it is very inefficient and may cause problems. All you'll need to do is change the one line where the collection is created and you should be good to go.
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can also look at this from the other direction. Why dos the calling method ask for an interface rather than a class?

By using an interface, the calling code doesn't have to change. If i write my calling code to expect a Dog class, what happens when i want to start processing Cats, Birds, or Fish?

If my calling code accepts a Pet interface, I can be on the beach in Fiji when someone decides we should start taking those other kinds of animals. my expecting a Pet interface works no matter what the animal they want to send me is.

If you have it hard-coded to expect a Dog, you can't just take in a Cat.
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
++Fred's post..

Really, that's the main reason. You will rarely change your list implementation - and if you do it's really not THAT much work to go through your code and fix it...

...but it's dumb to use a concrete implementation anyway, you get absolutely no benefit from returning an implementation type, and as Fred has said, your objects are less likely to play nice with API's that like Collections, Lists, Maps, etc.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Adam]: you get absolutely no benefit from returning an implementation type

Hm, I agree with you in general, but since you said "absolutely" I must disagree. You're obviously aware of this other thread discussing possible benefits of using an abstract class - or more generally, a class which can have at least some concrete method implementations in it - rather than an interface. We may well believe that these benefits are not enough to offset the dangers of doing this. But that's not the same as saying that there is absolutely no benefit to returning implementation types.
 
Adam Schaible
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,

These are two different things. There are thousands of possible scenarios - and I agree it usually doesn't make much sense to return a java.util.Comparable.

It really is a slippery slope - especially with collections and generics. I had a fairly long response but I don't think this forum is the place for a "rules engine" - there are simply too many situations to define, and sometimes the quality of two solutions are roughly equivilent, and the decider is consistency. I think the "process" here is to simply think about all of the possibilities and make the most logical choice.
 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulf, Just wanted to make sure that I understand this properly, I have given the following 2 approaches on this concept. Could you please help me on this ?

Approach-1
-----------

Original Base Code Today: LinkedList ref = new LinkedList();
Dependant Code Today : Recieves LinkedList

Original Base Code Tomorrow: ArrayList ref = new ArrayList();
Dependant Code Tomorrow: Recieves ArrayList

Result : Both Orginal Code and all code that depends on this MUST be recompiled

Approach-2
-----------

Original Base Code Today: List ref = new LinkedList();
Dependant Code Today : Recieves LinkedList polymorphically through List

Original Base Code Tomorrow: [List ref = new ArrayList();
Dependant Code Tomorrow : Recieves ArrayList polymorphically through List

Result : Only Orginal Code MUST be recompiled and all code that depends on this NEED NOT to be recompiled

In either cases Orginal Code must be recompiled (Means, only 50% beneficial). Only difference is dependant code need not to be compiled in second because
we are passing interface and caller is expecting interface.
Please let me know if I am giving wrong statemet or missing some piece.

Ulf Dittmer wrote:The benefit is that returning an interface makes it possible to change the implementation later on. E.g., you might decide after a while that you'd much rather use a LinkedList instead of an ArrayList. If the return type is "ArrayList", you're out of luck - all code that depends on it must be recompiled (and possibly rewritten if it makes use of ArrayList features that are not part of List). Had you declared the return type to be List, you could simply return a LinkedList instead.

Most of the time it is sufficient to know that the type will be a List (or Map), without the need to use other features of the implementing classes.

 
Ranch Hand
Posts: 147
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You don't have to just recompile the code, you have to rewrite parts of it. If I use a method in 60 places and want to change the return type, I have to rewrite the code in 61 places instead of just one.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic