aspose file tools*
The moose likes Beginning Java and the fly likes Why we return type Mostly Interface rather than Class? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why we return type Mostly Interface rather than Class?" Watch "Why we return type Mostly Interface rather than Class?" New topic
Author

Why we return type Mostly Interface rather than Class?

Mallik Avula
Ranch Hand

Joined: Nov 30, 2006
Posts: 86
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


Thanks & Regards<br />Mallik Avula<br />SCJP1.4
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
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.


Ping & DNS - my free Android networking tools app
Pavel Kubal
Ranch Hand

Joined: Mar 13, 2004
Posts: 356
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.
Bill Shirley
Ranch Hand

Joined: Nov 08, 2007
Posts: 457
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.


Bill Shirley - bshirley - frazerbilt.com
if (Posts < 30) you.read( JavaRanchFAQ);
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11402
    
  16

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.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Adam Schaible
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
++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.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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.


"I'm not back." - Bill Harding, Twister
Adam Schaible
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
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.
Harikrishna Gorrepati
Ranch Hand

Joined: Sep 23, 2010
Posts: 422
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.


OCPJP 6.0-81% | Preparing for OCWCD
http://www.certpal.com/blogs/cert-articles | http://sites.google.com/site/mostlyjava/scwcd |
Jan Hoppmann
Ranch Hand

Joined: Jul 19, 2010
Posts: 147

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.


Life is full of choices. Sometimes you make the good ones, and sometimes you have to kill all the witnesses.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why we return type Mostly Interface rather than Class?