What is the benefit of polymorphism using Collection interface to create ArrayList object?

Question

I studied polymorphism and understand that it can do dynamic method binding like below.

Assuming that class Animal is abstract class.

public class An         


        

Answer 1

Well, an arraylist has a dynamic size. The collection has no compile time checking, it must be cast typed. A collection contains only objects by reference. You can think of a collection as a "bag". And manipulation can be performed over the entire object. I'm also sure that the searching time for a collection is short compared to an ArrayList, but not positive. ArrayLists have more functionality and methods that can be called.

Answer 2

If you declare myList as ArrayList, you fix its concrete type. Everyone using it will depend on this concrete type, and it is easy to (even inadvertently) call methods which are specific to ArrayList. If sometime later you decide to change it to e.g. LinkedList or CopyOnWriteArrayList, you need to recompile - and possibly even change - client code. Programming for interfaces eliminates this risk.

Note that between Collection and ArrayList, there is another level of abstraction: the List interface. Typically the usage pattern of a list is very different from that of a map, set or queue. So the type of collection you need for a job is usually decided early on, and is not going to change. Declaring your variable as a List makes this decision clear, and gives its clients useful information regarding the contract this collection obeys. Collection OTOH is usually not very useful for more than iterating through its elements.

Answer 3

By declaring and using myList as a Collection, you are hiding the implementation choice you are making (in this case, that it is represented as an ArrayList). In general, this means that any things that depend on your piece of code will only rely on myList behaving as a Collection, not as an ArrayList in particular. That way if you decide to represent it as something else later on (a Set? A Linked List?) for whatever reason, you don't break anything else.

Answer 4

It's probably more common to write List<Something> myList = new ArrayList<Something>(); than to use Collection. Usually some aspects of it being a list are significant. The vagueness of Collection with regard to accepting duplicate elements whether it's a set or list (or whatever) underneath can be a pain.

That aside, the primary purpose is abstraction, or implementation independence. Do I actually care if the List I have is an ArrayList or a Vector? Probably not most of the time. My code is more flexible if it uses the most general interface that expresses what I need the object to do.

The easy example is, suppose you write a program using all ArrayLists, and then later it needs to support multiple users, so for thread safety you want to change all your ArrayLists to Vectors. If you've been passing around references to the Type ArrayList, you have to change every usage everywhere. If you've been passing around references to the Type List, you only have to change the places where you create them.

Also, sometimes the implementing class might not be something you can or want to import and use. For example when using a persistence provider like hibernate, the actual class that implements the Set interface could be a highly specialized custom implementation unique to the framework, or it could be plain old HashSet, depending on how the object got created. You don't care about the difference, it's just a Set to you.

Answer 5

The type you use in a local variable declaration (as in your ArrayList example) is not usually that significant. All you have to ensure is that the type of myList (the word to the left of the name 'myList') has to be more specific than the type of any method parameter that takes myList.

Consider:

ArrayList words = new ArrayList();
sort(words);
removeNames(words);

public void sort(Collection c)  ... blah blah blah

public void removeNames(List words) ...  

I could have replaced the type of 'words' to just be List. It doesn't make any difference to the readability or the behaviour of my program. I could not define 'words' to be Object though. That's too general.

On a related note, when you define a public method, you should give careful consideration about the types of the method's parameters, since this has a direct effect on what the caller can pass in. If I defined sort differently:

ArrayList words = new ArrayList();

// this line will cause a compilation error.
sort(words);

public void sort(LinkedList c)  ... blah blah blah

The definition of sort is now very restrictive. In the first example, the sort method allows any object as the parameter, so long as it implements Collection. In the second example, sort only allows a LinkedList, it won't accept anything else (ArrayLists, HashSets, TreeSets and many others). The scenarios in which the sort method can be used are now quite limited. This might be for good reason; the implementation of sort may rely on a feature of the LinkedList data structure. It is only bad to define sort this way if people using this code want a sort algorithm that works for things other than LinkedLists.

One of the main skills in writing java libraries is deciding the types of method parameters. How general do you want to be?

Answer 6

Collection is a supertype of ArrayList. If you only need the functionality provided by Collection, it's good practice because you're explicitly indicating what functionality you need in the variable declaration. That you choose an ArrayList in the initialization is irrelevant (though a good default choice); the declaration that it's a Collection tells you and any future coder exactly what contract you care about.