PMD would report a violation for:
ArrayList<Object> list = new ArrayList<Object>();
The violation was "Avoid using implementation types like 'ArrayList'; use the interface instead".
The following line would correct the violation:
List<Object> list = new ArrayList<Object>();
Why should the latter with List be used instead of ArrayList?
Using interfaces over concrete types is the key for good encapsulation and for loose coupling your code.
It's even a good idea to follow this practice when writing your own APIs. If you do, you'll find later that it's easier to add unit tests to your code (using Mocking techniques), and to change the underlying implementation if needed in the future.
Here's a good article on the subject.
Hope it helps!
This is preferred because you decouple your code from the implementation of the list. Using the interface lets you easily change the implementation, ArrayList in this case, to another list implementation without changing any of the rest of the code as long as it only uses methods defined in List.
In general I agree that decoupling interface from implementation is a good thing and will make your code easier to maintain.
There are, however, exceptions that you must consider. Accessing objects through interfaces adds an additional layer of indirection that will make your code slower.
For interest I ran an experiment that generated ten billion sequential accesses to a 1 million length ArrayList. On my 2.4Ghz MacBook, accessing the ArrayList through a List interface took 2.10 seconds on average, when declaring it of type ArrayList it took on average 1.67 seconds.
If you are working with large lists, deep inside an inner loop or frequently called function, then this is something to consider.
ArrayList and LinkedList are two implementations of a List, which is an ordered collection of items. Logic-wise it doesn't matter if you use an ArrayList or a LinkedList, so you shouldn't constrain the type to be that.
This contrasts with say, Collection and List, which are different things (List implies sorting, Collection does not).
Why should the latter with List be used instead of ArrayList?
It's a good practice : Program to interface rather than implementation
By replacing ArrayList with List, you can change List implementation in future as below depending on your business use case.
List<Object> list = new LinkedList<Object>();
/* Doubly-linked list implementation of the List and Deque interfaces.
Implements all optional list operations, and permits all elements (including null).*/
OR
List<Object> list = new CopyOnWriteArrayList<Object>();
/* A thread-safe variant of ArrayList in which all mutative operations
(add, set, and so on) are implemented by making a fresh copy of the underlying array.*/
OR
List<Object> list = new Stack<Object>();
/* The Stack class represents a last-in-first-out (LIFO) stack of objects.*/
OR
some other List specific implementation.
List interface defines contract and specific implementation of List can be changed. In this way, interface and implementation are loosely coupled.
Related SE question:
What does it mean to "program to an interface"?
Even for local variables, using the interface over the concrete class helps. You may end up calling a method that is outside the interface and then it is difficult to change the implementation of the List if necessary.
Also, it is best to use the least specific class or interface in a declaration. If element order does not matter, use a Collection instead of a List. That gives your code the maximum flexibility.
Properties of your classes/interfaces should be exposed through interfaces because it gives your classes a contract of behavior to use, regardless of the implementation.
However...
In local variable declarations, it makes little sense to do this:
public void someMethod() {
List theList = new ArrayList();
//do stuff with the list
}
If its a local variable, just use the type. It is still implicitly upcastable to its appropriate interface, and your methods should hopefully accept the interface types for its arguments, but for local variables, it makes total sense to use the implementation type as a container, just in case you do need the implementation-specific functionality.
In general for your line of code it does not make sense to bother with interfaces. But, if we are talking about APIs there is a really good reason. I got small class
class Counter {
static int sizeOf(List<?> items) {
return items.size();
}
}
In this case is usage of interface required. Because I want to count size of every possible implementation including my own custom. class MyList extends AbstractList<String>....
Interface is exposed to the end user. One class can implement multiple interface. User who have expose to specific interface have access to some specific behavior which are defined in that particular interface.
One interface also have multiple implementation. Based on the scenario system will work with different scenario (Implementation of the interface).
let me know if you need more explanation.
The interface often has better representation in the debugger view than the concrete class.
Related
I just started with lists in Java and I'm confused with all this.
So basically we have ArrayList and LinkedList which can be defined like
LinkedList<String> s = new LinkedList<String>();
ArrayList<String> s = new ArrayList<String>();
But then we also have LinkedIntList which can be defined like for example:
class LinkedIntList {
private ListNode first;
private int size;
LinkedIntList () {
first=null;
size=0;
}
LinkedIntList(LinkedIntList l) {
first = l.getFirst();
size=l.size();
}
ListNode getFirst() {return first;}
int size() {return size;}
}
But this is my problem, why define LinkedIntList using a class? What is the difference comparing to LinkedLists where we just define like I stated.
I can't understand why a class is being used. If this is a 'new type' of array why using a class instead of declaring it normally?
Sorry if this sounds weird, but I'm a beginner and really need help at this.
Thank you!
A List in java, is an ordered collection. I suppose you are a beginner and confused with syntax. If you have java decompiler, you can see that LinkedList and ArrayList are also classes. Which means somewhere some good person has done the coding for you and provided you a class which is similar to your "LinkedIntList" and provided you out of the box.
You don't need to create a new class if java provides sufficient functionality for you.
But sometimes, the out of the box classes are not sufficient for our requirements. In that case we have to write our own implementation of classes, such as your class "LinkedIntList".
In this case, it seems you need size and one element hence you are creating it on your own.
LinkedList is a class defined in the java.util package, and it's already provided to you. It exploits a feature called Generics that allows you to provide the type of objects that will populate the list. You basically take it as a black box: in most cases, you don't care about LinkedList actual implementation, but only about its interface (that is, the methods it exposes to you).
The class LinkedIntList that you provided does not feature genericity, but is simply an implementation of a linked list where each item is a ListNode. I guess a ListNode contains an integer, otherwise the name LinkedIntList wouldn't make much sense.
Anyway, you could discard this implementation (although is good for learning) and simply declare
LinkedList<Integer> myLinkedList = new LinkedList<Integer>();
If you want to know more about generics, take a look at the java tutorials.
In your first example,
LinkedList<String> s = new LinkedList<String>();
it is the implementation of LinkedList defined in the stardard library, specifically from package java.util. See here: http://docs.oracle.com/javase/7/docs/api/java/util/LinkedList.html
You can look for its source code (1000+ lines long so I won't be posting it here) and compare it to your custom implementation of LinkedIntList.
Basically, Java already provided a default implementation of LinkedList(your first example) but everyone can still write(a class) and use their own implementation (your second example).
You're question isn't clear, but I'll try to explain to you what Lists are essentially.
Lists are a type of data structure, not only in Java but in a lot of programming language. Arrays are also a type of data structure. Data structures hold and manage data in an organized manner.
In Java, the main difference between a List and an Array is that a List has dynamic size, while an Array is of fixed size set when the Array was declared.
All Lists in Java are implementation of the List interface. If you don't know what interfaces are, I suggest you learn about it, but basically it means that all Lists can do the same basic set of things for you, but do them differently internally.
For example, ArrayList uses Arrays internally in order to expand or diminish the List as necessary (implement the dynamic size). LinkedList implements things differently internally, using nodes that are connected to each other. But they both offer the same basic sets of operations to the programmer, defined in the List interface (although one may offer additional methods the other doesn't).
Because the differ in their inner implementation, they might differ in performance for different operations. They have different algorithms to do things (for example, access a value in an index), with different 'speeds' (complexities) of doing so.
Most of the time ArrayList will be the right, simpler choice. This answer talks about when to prefer one over the other.
Hope this helps.
A java List is an ordered collection of objects, this java.util.List is actually an interface (contract) that defined what a list should behave like.
There are multiple variations (implementations) of List in the java standard JDK, while each is different from the other, they honor the contract defined in List (the ordered aspect for example). These implementations are concrete classes and you choose from in your code.
LinkedList and ArrayList you mentioned are JDK implementations of List.
The class you shared (LinkedIntList) is a custom made structure of objects, that neither part of the JDK, nor implement the java List interface.
LinkedList is a part of Java platform class in java.util package and it is widely used in different tasks. And it supports Generics .
LinkedIntList is a custom implementation just to show you how single-linked list coudl be implemented.
You can find more about different algorithms and structures and also complexity here
Why are interfaces used in Java when each method must be typed out again in the actual implementation? What's an example of a situation where writing out an interface makes things easier?
Interfaces define a contract, not an implementation. This allows you to divorce yourself from the actual implementation of an interface- as long as the implementation satisfies the contract, you're happy.
Say you call a method that returns a List (which is an interface). You can use that List because you know it has List functions like get() and add(). You don't have to worry about what kind of list it is. If the List happens to be an ArrayList and then the method changes to return a LinkedList instead, you don't have to change your code at all, since both are guaranteed to have the List functions.
One of the biggest benefits of interfaces is that you can use the interface in the method arguments and return type. For example, you can write:
public List join (List list1, List list2)
{
// some complicated stuff using list1.size() and list2.get() etc
}
Interfaces have many advantages.
Assuming the following code:
public class MyClass {
public List<String> getNames () {
List<String> names = new ArrayList<String> ();
// Populate list of names
return names;
}
}
As Kevin Workman mentioned in his excellent answer, an interface is used to define the contract that implenting classes will have to fulfill. In the above case, the getNames method states that it will return an instance of the interface List. However, the contract does not force you to use a specific List implementation; any concrete class that implements List can be used. In this case, an ArrayList was chosen.
Later on in your project, if you end up realizing that a LinkedList would be a better implementation for your application, you can easily change List<String> names = new ArrayList<String> (); to List<String> names = new LinkedList<String> ();, without having to change the method signature, or the rest of the existing code inside the method. This is a good practice, and it can prevent many problems and/or time loss in your projects.
Additionally, using interfaces allows you (or clients of your code) to define the concrete implementation that best suit their needs. In the case of Map implementations, some are faster, some are more space efficient.
Another advantage of interfaces can be appreciated when building a unit tests set. Most of the mocking framework, if not all of them, work with interfaces. It allows you to build tests that do not require to have every concrete test implementation hand coded, and allows the test code base to be much smaller/simpler.
When building an API that will be used by other developers, the use of interfaces can make your API much simpler, and facilitate your clients' experience with your API. An example of this would be the DOM XML implementation provided in Java. If you look at the API, there's pretty much only interfaces, no concrete classes are exposed. During the maintenance of this API, the developers can add/change/delete any concrete implementation without the fear of breaking backward compatibility with existing client code.
If they had made the concrete implementations public, they would have had their hands tied throughout the API's lifetime. For instance, assume they provided a faulty Element public implementation named BuggedElement, and clients directly used it in their code. From this point on, they would be forced to maintain this implementation, rather than just removing it and writing a new implementation, otherwise existing projects using this concrete implementation would be forced to re-write pieces of code referring to BuggedElement.
But, since they opted to only provide interfaces in their public API, they have the luxury of either modifying existing implementations, or getting rid of them and writing new ones, and they will never break clients' code.
I'm creating a library to be used by people but why should my method return a List instead of an ArrayList?
Because if the user knows the real type is an ArrayList he will use the accessor [] in a loop instead of iterator but if he doesn't know he will use an iterator.
Same question for LinkedList, if the return type is a List he won't be able to use the correct accessor.
Am I right?
Returning List will make it possible for users of your library to use anything that implements a List interface, while using an ArrayList will force them to use an ArrayList.
If in the future, you as a library creator decide to change your internal implementation, that changes will be hidden from the end user by the generic interface to your library.
Because the users of your library should never know that you are using an ArrayList internally.
For example, say you return an ArrayList and lots of people have started using your library. Now if you suddenly realize a LinkedList better suits your purpose, then you break compatibility for all the folks who are presently using your code.
This is why it is always better to code to an interface, not an implementation, and even more so when you are writing code that is specifically meant to be re-used. The interface (List in this case) acts as a contract between your code and the client's code. It tells them what your code does (interface), without telling them how it does it (by not exposing the implementation).
Return an interface (or failing that a super class?) if possible. This way the method can have a broader application if overriden. This might prevent some class-specific methods from being available on the returned object but there's nothing stopping a programmer taking the List data and copying it to whatever Collection they prefer to use.
List myList = new MyLibrary().getList();
ArrayList myArrayList = new ArrayList(myList);
LinkedList myLinkedList = new LinkedList(myList);
They don't have to use an iterator - the List interface supports get(int index) as a method. If you want flexibility to change the underlying container to anything supporting the list interface, use List. If specific ArrayList methods are required on what you return, use ArrayList.
Because your user can make from your List either ArrayList or LinkedList, you will leave him a choice. It's called Programming to Interface. You should give users of your API as much freedom as you can and this technique is one of the ways how to achieve it.
1. Its the concept of Interface Polymorphism.
2. Its better to have List<My_Obj> arr = new ArrayList<My_Obj>;
3. Suppose you want to use LinkedList instead of ArrayList as somepoint, then you donot
need to worry abt how to do it..
If You are returning List then it is possible for users of your library to use anything that implements a List interface. It may be Array List or Linked List.
I typically choose the most general type possible. In this case, you could return a type that's even more general than a List, such as Collection or Iterable.
By returning Iterable, the compiler will prevent the calling code from attempting to add elements to your list. This is much stronger than relying on Collections.unmodifiableList() to fail at runtime.
Using more general types also gives you more room to manoeuvre in the future. Perhaps your method's going to load your data from a streaming source rather than an in-memory source: then Iterable becomes a much more suitable than List.
This question already has answers here:
Type List vs type ArrayList in Java [duplicate]
(15 answers)
Closed 10 years ago.
What are the fundamental differences between the two objects? Is one more efficient? Does one have more methods?
List is in interface while ArrayList is a class.
See ArrayList, and List.
E.g, you can't use this setup:
List<String> list = new List<String>();... Because it's an interface.
However, this works:
ArrayList<String> arrayList = new ArrayList<String>();
Also... You can do as duffymo says below, which is more or less the same as implementing the List interface (making your own list implementation).
Consider a line like the following:
List<String> names = new ArrayList<String>();
If you're new to object-oriented architectures, you might have expected instead to see something like ArrayList<String> names = new ArrayList<String>();. After all, you've just said that it's a new ArrayList, so shouldn't you store it in a variable of type ArrayList?
Well, you certainly can do that. However, List is an interface--like a template of sorts--that ArrayList is said to inherit. It is a contract that says "anytime you use a List implementation, you can expect these methods to be available". In the case of List, the methods are things like add, get, etc.
But ArrayList is only one implementation of List. There are others, such as LinkedList. The two have the same interface, and can be used the same way, but work very differently behind the scenes. Where ArrayList is "random" access, meaning that it directly finds a specific element of the array without iterating through the whole list, LinkedList does have to start from the first element and go one-by-one until it gets to the element you need.
The thing is, while you do need to specify which you want when you create the object, you generally only need to communicate no more than the fact that it is a List, so you simply say that's what it is. List communicates that you have a collection that is intended to be in the order that it is given. If you don't need to communicate that much, you might consider passing it around as a Collection, which is another interface (a super-interface of List). Or, if all you need to communicate is that you can iterate over it, you might even call it an Iterable.
List is an interface; ArrayList is a class that implements the List interface.
Interfaces define the method signatures that are required, but say nothing about how they are implemented.
Classes that implement an interface promise to provide public implementations of methods with the identical signatures declared by the interface.
A List defines the interface that ArrayList uses, that allows it to implement methods that will allow all other classes that implement List to be used together or in a similar way. An ArrayList is always also a List, but an List isn't necessarily an ArrayList.
That is, ArrayList implements List (among a few other interfaces).
How to use List and ArrayList, or other implementation of List, is Polymorphism and Inheritance, and also the reason why for using languages such as Java.
In simplicity, Polymorphism is many forms while Inheritance is reuse.
There can be many kinds of concrete and ready to us List that is available to you, such as ArrayList, Vector, LinkedList and Stack. The decision to use which comes from you, and if you look at the List API, you would notice that all of these List implementations extend in one way or another from List.
According to the java docs, List is just an interface, and ArrayList is one of the classes that implement it. There is no inherent efficiency advantage to using ArralyList specifically instead of List-typed references to an ArrayList object.
However, when it comes to "efficiency", there can be a difference between different implementations of the List interface. For instance there can be a small efficiency difference between a LinkedList and an ArrayList, depending on how you're using them.
To quote the java docs on the ArrayList page,
The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
In other words, the performance difference will probably be negligible, but you may see some advantage from using an ArrayList (as opposed to a LinkedList).
In case you're interested, ArrayList is implemented with an array that is resized from time to time (most likely whenever your collection doubles in size), which is quite different from the implementation of a LinkedList (see wikipedia for details).
This has been bugging me for a while and have yet to find an acceptable answer. Assuming a class which is either a subclass or implements an interface why would I use the Parent class or Interface as the Type i.e.
List list = new ArrayList();
Vehicle car = new car();
In terms of the ArrayList this now only gives me access to the List methods. If I have a method that takes a List as a parameter then I can pass either a List or an ArrayList to it as the ArrayList IS A List. Obviously within the method I can only use the List methods but I can't see a reason to declare it's type as List. As far as I can see it just restricts me to the methods I'm allow to use elsewhere in the code.
A scenario where List list = new ArrayList() is better than ArrayList list = new ArrayList() would be much appreciated.
You write a program that passes lists around several classes and methods. You now want to use it in a multi threading environment. If you were sensible and declared everything as List, you can now make a single change to one line of code:
List list = Colllections.synchronizedList(new ArrayList());
If you had declared the list as an ArrayList, you would instead have to re-write your entire program. The moral of the story - always program to the least restrictive interface that your code requires.
Using the interface or parent type is generally recommended if you only need the functionality of the parent type. The idea is to explicitly document that you don't really care about the implementation, thus making it easier to swap out the concrete class for a different one later.
A good example are the Java collection classes:
If you always use List, Set etc. instead of e.g. ArrayList, you can later switch from ArrayList to LinkedList if you find that it gives e.g. better performance. To do that, just change the constructors (you don't even have to change them all, you can mix). The rest of the code still sees an instance of List and continues working.
If you actually used ArrayList explicitly, you'd have to change it everywhere it's used. If you don't actually need an ArrayList specifically, there's nothing to be gained from using it over the interface.
That's why it's generally recommended (e.g. in "Effective Java" (J.Bloch), Item 52: "Refer to Objects by their interfaces".) to only use interfaces if possible.
Also see this related question: Why classes tend to be defined as interface nowadays?
The key is exactly that the interface or base class restricts what you can do with the variable. For example, if you refactor your code later to use another implementation of that interface or base class, you won't have anything to fear -- you didn't rely on the actual type's identity.
Another thing is that it often makes reading the code easier, e.g. if your method's return type is List you might find it more readable to return a variable of type List.
An interface specifies a contract (what does this thing do), an implementation class specifies the implementation details (how does it do it).
According to good OOP practice, your application code should not be tied to implementation details of other classes. Using an interface keeps your application loosely coupled (read: Coupling)
Also, using an interface lets client code pass in different implementations and apply the decorator pattern using methods like Collections.synchronizedList(), Collections.unmodifiableList() etc.
A scenario where List list = new
ArrayList() is better than ArrayList
list = new ArrayList() would be much
appreciated.
One concrete example: if it's a field declaration and you have a setList(), which of course should take a List parameter to be flexible.
For local variables (and fields with no setters), there is very little concrete benefit in using the interface type. Many people will do it anyway on general principle.
You were right. In these cases, the variables are fields or local variables, they are not public interface, they are implementation details. Implementation detail should be detailed. You should call an ArrayList an ArrayList, because you just deliberately chose it for your implementation.
People who recycle cliches: look at your post and think a little bit more. It's nonsense.
My previous answer that was downvoted to death:
Use interface or type for variable definition in java?