It's a good OO practice to do so. Suppose that you change your collection from LinkedList to ArrayList. To the caller, it doesn't need to know how the collection is being implemented. What it knows is that both LinkedList and ArrayList implement List.
First off, you don't have to declare your reference variables that way. It's perfectly legal to declare:
LinkedList myList = new LinkedList();
You can also declare:
Collection myCollection = new LinkedList();
It is considered by many to be a best practice to declare your reference variables with the most abstract type you can get away with, this ensures that you can only use those methods that are available to the reference type you declare it as. That way if you want to swap an implementation to a different kind of List in the future, you only have to change the declaration and nothing else.
In my opinion, this type of coding is less important at the site of instantiation, than as a return type or parameter to a method or constructor.
This type of signature is clearly preferable to returning a specific type of List (like a LinkedList) because now the clients to this method never should know or care about the concrete return type of the method. Now if you want to swap the type of list you return with an ArrayList, or a NewFangledBellsAndWhistlesList, you aren't breaking any client code. [ August 21, 2008: Message edited by: Garrett Rowe ]
Post by:autobot
Hey! Wanna see my flashlight? It looks like this tiny ad:
a bit of art, as a gift, the permaculture playing cards