Why to return an Interface (List) an not the Implemantation (ArrayList)?

E

etienno

Hi,

I have a simple question about return type. Usually, I dont think much
about it, I usually returns the interface.

Per example, if I have a methode that returns an ArrayList, I usually
return a List in its signature:

public List getStuffList(){
return new ArrayList();
}

I need to explain that to my collegue (some returns Vector and
ArrayList). I would like to explain them that returning a List is
"better", but I cannot find much argument about it.... Yes, the
implementation can change without changing the signature, but what
else? Could someone gives me a better answer?

Tks

Etienne
 
I

Ingo R. Homann

Hi,
...
> public List getStuffList(){
> return new ArrayList();
> }
> ...
Yes, the
implementation can change without changing the signature

That is the one and only reason! Returning the interface-type prevents
unnecessary dependancies in the code:

Consider, you are returning a "Vector" instead of a "List":

public Vector getStuffList(){
return new Vector();
}

It is possible, that the caller of getStuffList() calls the method
"elementAt()" instead of "get()" on the returned Object:

myObj.getStuffList().elementAt(i)

Now consider, you are refactoring or improving the method
"getStuffList()" because you realise that Vector is synchronized and an
unsynchronized List (e.g. ArrayList) would be better. So, you replace
Vector with ArrayList:

public ArrayList getStuffList(){
return new ArrayList();
}

That would cause the problem that the caller of the method would have to
be changed as well:

myObj.getStuffList().get(i)

If the signature would have been 'List' from the beginning on, then no
changes of the caller would be necessary!

Ciao,
Ingo
 
L

Lothar Kimmeringer

etienno said:
I need to explain that to my collegue (some returns Vector and
ArrayList). I would like to explain them that returning a List is
"better", but I cannot find much argument about it.... Yes, the
implementation can change without changing the signature, but what
else? Could someone gives me a better answer?

Using the interface instead of the implementation is better,
because of the reason you said. You can change the used
implementation without problem. And changing this happens,
it's not a only a theoretical contruct. Happened here and
will happen at your place as well.

If you change the signature of a method from e.g. java.util.LinkedList
to java.util.ArrayList (or vice versa) all applications using this
class (e.g. residing inside a jar) have to be recompiled otherwise
you will get NoSuchMethodErrors during runtime.

All that can be avoided when using java.util.List. BTW. To
avoid performance-issues it's better to iterate through
a list using

Iterator it myList.iterator();
while (it.hasNext()){
Object o = it.next();
// do something
}

than

for (int i = 0; i < myList.size(); i++){
Object o = myList.get(i);
// do something
}

Especially if you don't know the concrete implementation being
used. LinkedList ist quite slow when doing random access.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
D

Darryl L. Pierce

etienno said:
I need to explain that to my collegue (some returns Vector and
ArrayList). I would like to explain them that returning a List is
"better", but I cannot find much argument about it.... Yes, the
implementation can change without changing the signature, but what
else? Could someone gives me a better answer?

It's partially about simplicity: return only the type that meets your
requirement. Interfaces necessarily meet that guideline.

It's also about refactoring ease: if you lock into ArrayList as the type
your code uses, then you would have to majorly refactor code if you decided
to go with a LinkedList instead for performance reasons. And I would highly
doubt that the requirements are such that you *have* to use an
implementation rather than an interface; ie, since the implementation
details are hidden, coupling your code to a specific implementation makes
the refactor effort again far more difficult when you find yourself needing
to replace ArrayList with LinkedList.
 
L

Lew

In addition to the other fine answers here, Joshua Bloch has a segment on this
matter in his excellent book, /Effective Java/.

Interface-driven design, or "Inversion of Control", is the basis of patterns
like the Factory, and of frameworks like Spring.

- Lew
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top