Reading other people\'s code, I\'ve seen a lot of:
List ints = new ArrayList();
Map map = new HashMap();
Quick answer? Using interfaces and superclasses increases the portability and maintainability of your code, principally by hiding implementation detail. Take the following hypothetical example:
class Account {
private Collection<Transaction> transactions;
public Account() {
super();
transactions = new ArrayList<Transaction>(4);
}
public Collection<Transaction> getTransactions() {
return transactions;
}
}
I've declared a contract for an Account that states that the transactions posted to the account can be retrieved as a Collection. The callers of my code don't have to care what kind of collection my method actually returns, and shouldn't. And that frees me to change up the internal implementation if I need to, without impacting (aka breaking) unknown number of clients. So to wit, if I discover that I need to impose some kind of uniqueness on my transactions, I can change the implementation shown above from an ArrayList to a HashSet, with no negative impact on anyone using my class.
public Account() {
super();
transactions = new HashSet<Transaction>(4);
}
As far as your second question, I can say that you use the principal of portability and encapsulation wherever they make sense. There are not a terrible lot of CharSequence implementations out there, and String is by far the most used common. So you just won't see alot of developers declaring CharSequence variables in their code.
List<E> ints = new ArrayList<E>();
If you write some code that deals only with List
then it will work for any class that implements List
(e.g. LinkedList
, etc). But, if your code directly deals with ArrayList
then it's limited to ArrayList
.
CharSequence s = new String("String");
Manually instantiating a String
object is not good. You should use string literal instead. I am just guessing the reason that you don't see CharSequence
might because it's quite new and also, strings are immutable.
The reason behind this is not technical but the stuff you have to read between the lines of code: The List
and Map
examples says: "I'm only interested in basic list/map stuff, basically you can use anything here." An extreme example of that would be
Iterable<Foo> items = new ArrayList<Foo>();
when you really only want to do some stuff for each thing.
As an added bonus this makes it a little easier to refactor the code later into common utility classes/methods where the concrete type is not required. Or do you want to code your algorithm multiple times for each kind of collection?
The String
example on the other hand is not seen wildly, because a) String
is special class in Java - each "foo"
literal is automatically a String
and sooner or later you have to give the characters to some method which only accepts String
and b) the CharSequence
is really ahh minimal. It does not even support Unicode beyond the BMP properly and it misses most query/manipulation methods of String
.
Is a design principle that you program to the interface and not to the implementation.
That way you may provide later a new implementation to the same interface.
From the above link Eric Gamma explains:
This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java development tools like Eclipse even write this statement for you. Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial.
Here, the termin interface
refers not only to the Java artifact, but the public interface a given object has, which is basically composed of the methods it has, so, it could be a Java interface ( like List
in your example ) or a concrete superclass.
So in your example if you ever want to use a LinkedList
instead it would be harder because the type is already declared as ArrayList
when just list would've been enough.
Of course, if you need specific methods from a given implementation, you have to declare it of that type.
I hope this helps.
It is just easier to think of String
as of String
. As well as it's easier (and more beneficial) to think of WhateverList
as of List
.
The bonuses are discussed many times, but in brief you simply separate the concerns: when you need a CharSequence
, you use it. It's highly unlikely that you need ArrayList
only: usually, any List will do.
You do this to make sure later when working with the variable you (or anyone using your classes) won't rely on methods specific for the implementation chosen (ArrayList, HashMap, etc.)