List list = new ArrayList(); Help understanding please?
I recently took a java course at work and the instructor said that in the statement:
List list = new ArrayList();
The left side was the compile time side and the right side was the run time side, I didnt quite understand this and I didnt get a chance to ask. Could anyone explain this?
Could somebody also tell me if my understanding of the above statement is in anyway correct?
I gather that I am declaring a pointer to a List object at compile time, and because ArrayList is a type of List the compiler doesnt complain about this statement.
ArrayList offers additional functionality to List, at runtime when this class is loaded and the objects are created the List pointer now points to an ArrayList object.
I know that the object list will only have the methods that are declared in the List interface, I am not sure why though, I hope somebody can also explain this to me.
Thanks
Yeah, you seem to understand it. It's pretty much exactly what you said. You can only use the methods in the List class/interface/whatever it is because that's what you're using it as. I suppose it's like that because Java is a type safe language. Besides, if you wanted to use methods in the ArrayList class, you should have declared it as an ArrayList.
As for the compile time side and run time side statement, I'm not really sure what he's talking about. Possibly that at compile time it will treat the list object as a List and only at runtime will it treat it, in anyway, as an ArrayList. At any rate, I wouldn't worry too much about that, you seem to have a strong understanding of the language. Alot of people will probably tell you things in their own terminology that will just confuse you, best not to get too hung up on it.
I'll attempt to explain this in terms of how I learned it.
> I recently took a java course at work and the
> instructor said that in the statement:
>
> List list = new ArrayList();
>
> The left side was the compile time side and the right
> side was the run time side, I didnt quite understand
> this and I didnt get a chance to ask. Could anyone
> explain this?
I've never heard of the left/right side compile/run time thing before.
> Could somebody also tell me if my understanding of
> the above statement is in anyway correct?
>
> I gather that I am declaring a pointer to a List
> object at compile time, and because ArrayList is a
> type of List the compiler doesnt complain about this
> statement.
Right, but in java it's called a reference, not a pointer. It seemy nitpicky, but it helps to differentiate it from c++ pointers for instance, which allow pointer arithmetic, etc. The List interface defines a type. Since ArrayList implements the List interface, you can say that ArrayList is a type of List. You can refer to the ArrayList object with an ArrayList typed reference, or with a reference of any type that ArrayList implements or extends. Here's the type heirarchy for ArrayList from the api:
java.lang.Object
extended by java.util.AbstractCollection<E>
extended by java.util.AbstractList<E>
extended by java.util.ArrayList<E>
You can see that ArrayList also extends AbstractList, AbstractCollection, and Object. You could polymorph that ArrayList object and store it in a reference of any of those types. By doing that, you haven't changed the object itself, it's still an ArrayList. But since you only operate on objects through their reference, it's the type of the reference that determines which methods you can call on it. If you cast it to an AbstractCollection, you can only call methods defined by AbstractCollection on it, but since the object is an ArrayList, the version of that method that's implemented in ArrayList will be executed. I hope that makes sense.
> ArrayList offers additional functionality to List, at
> runtime when this class is loaded and the objects are
> created the List pointer now points to an ArrayList
> object.
Right, since you're looking at the object as if it were a List, you can't call ArrayList methods on it. If you needed to call an ArrayList specific method on that object, you could cast it back to an ArrayList from a List, and call the method. That kind of defeats the purpose of using the interface type since you're then bound to the ArrayList implementation.
> I know that the object list will only have the
> methods that are declared in the List interface, I am
> not sure why though, I hope somebody can also explain
> this to me.
The point of using the interface like that is that you only need an object that behaves like a List, meaning you can add elements to it, remove them, track the list's size, etc. To use it, you don't need to care how it's implemented. So you implement the List interface in the ArrayList class, then use that implementation to provide the functionality defined by List. When you tell List to add an element, it's the ArrayList that's doing it, but if you wanted to switch to a LinkedList (which also implements List), you could do that without affecting the code that just uses List.
> Thanks
Someone else can probably explain that more concisely, but that's how I understand it.
Thanks for you answers, they go a long way to helping me understand this. I didnt know that an objects methods are determined by its reference, but this makes things a lot clearer for me.Cheers.
public class Buffer {
private List l = new ArrayList();
public List getBufferList() {
return this.l;
}
public void setBufferList(List x) {
this.l = x;
}
}
The ArrayList object is encapsulated. The get/set methods are used to ask the Buffer class for its data. The data, i.e. ArrayList, is not exposed and there is no direct access. This is how encrapsulation works.
The Buffer class can change its internal implementation without effecting any client objects that use the Buffer's List.
For example, ArrayList can be changed to a LinkedList or a Vector.
private List l = new LinkedList();
private List l = new Vector();
Personally, I prefer the following:
private Collection l = new ArrayList();
> public class Buffer {
>private List l = new ArrayList();
>public List getBufferList() {
>return this.l;
>
>public void setBufferList(List x) {
>this.l = x;
> }
> }
>
> The ArrayList object is encapsulated. The get/set
> methods are used to ask the Buffer class for its
> data. The data, i.e. ArrayList, is not exposed and
> there is no direct access. This is how encrapsulation
> works.
>
> The Buffer class can change its internal
> implementation without effecting any client objects
> that use the Buffer's List.
>
> For example, ArrayList can be changed to a LinkedList
> or a Vector.
> >private List l = new LinkedList();
>private List l = new Vector();
> Personally, I prefer the following:
>
> private Collection l = new ArrayList();
How can you prefer that? Surely it's not a matter of taste, but a matter of appropriateness. For a start, if you need to retrieve an object at a particular index, Collection isn't good enough. If you need a list iterator, Collection isn't good enough. If you wish to make it clear that the Collection is not ordered, Collection is the man for the job. Of course, since Java 5, things get muddier still, since often you can abstract even further away, by merely using Iterable :-)
private Collection list = new ArrayList();
It is still an instance of ArrayList. When a client gets the reference, it is only wearing a Collection uniform, but inside it is still an ArrayList object.
To get an Iterator, you call the iterator() method of the Collection interface. What you get is an Iterator for the ArrayList.
When the ArrayList instance is traveling with his Collection uniform on, he still has an indexOf method at his disposal.
int i = list.indexOf(obj);
Wearing a Collection uniform does not change the behavior of the ArrayList object. It allows him to move about freely, and also is beneficial if the internal implementation maybe has to change.
> private Collection list = new
> ArrayList();
>
> It is still an instance of ArrayList. When a client
> gets the reference, it is only wearing a Collection
> uniform, but inside it is still an ArrayList object.
>
> To get an Iterator, you call the iterator() method of
> the Collection interface. What you get is an Iterator
> for the ArrayList.
But the Collection interface doesn't expose ListIterator, which is bi-directional.
> When the ArrayList instance is traveling with his
> Collection uniform on, he still has an indexOf method
> at his disposal.
>
> int i = list.indexOf(obj);
Not so. Collection does not expose that method, either. Why would it? A Collection implies an unordered 'bag', indexes are irrelevant. That code snippet cannot compile if list is a Collection, though
> Wearing a Collection uniform does not change the
> behavior of the ArrayList object. It allows him to
> move about freely, and also is beneficial if the
> internal implementation maybe has to change.
All of which is true for List, as well. I'm pointing out that Collection is not always the most suitable abstraction, particularly if you're dealing with indexed elements. Merely stating that one prefers Collection over List does not present a good case for doing so. There are many cases where List would be a better abstraction for ArrayList than Collection would, and indeed since 1.5, there are many cases where Iterable would be more suitable than Collection, too. But I do understand that you were - quite rightly - illustrating that List is not the only way to usefully dereference an ArrayList, as many people seem to believe
> All of which is true for List, as well. I'm pointing
> out that Collection is not always the most suitable
> abstraction, particularly if you're dealing with
> indexed elements.
This is basic understanding. I don't see the need to state basics in my sentences.
My sentence could have included the obvious, but that means extra key strokes.
Personally, I prefer the following when it is suitable and when I don't have to use an index to find objects.
> > All of which is true for List, as well. I'm
> pointing
> > out that Collection is not always the most
> suitable
> > abstraction, particularly if you're dealing with
> > indexed elements.
>
> This is basic understanding. I don't see the need to
> state basics in my sentences.
>
> My sentence could have included the obvious, but that
> means extra key strokes.
>
> Personally, I prefer the following when it is
> suitable and when I don't have to use an index to
> find objects.
These things may be obvious to you or I, but in a thread where the OP has explicitly said he does not understand why we use these abstractions, it is harmful to imply that Collection is a preferable abstraction to List, without exploring that further. Were someone to take your first post on face value, we would soon be hearing from them asking how to get a specific indexed element out of a Collection
> This is basic understanding. I don't see the need to
> state basics in my sentences.
Actually, you generally do, when the originator of the conversation tells you he's just learning the basics.
> My sentence could have included the obvious, but that
> means extra key strokes.
Since "efficiency of presentation" appears to be desirable:
"An interface defines the contract between the an object and its users. In the original sample, the desired contract was the behavior defined by List. ArrayList was the specific implementation that the coder chose to implement that contract."
Given that, replacing List with Collection isn't a useful addition to the conversation, and is likely to only confuse the OP, who is clearly learning all of this for the first time.
"Saving keystrokes" is useful only to the degree that it doesn't impair the goal of the conversation - which, in this case, is helping someone understand the difference between interface and implementation, and what an interface is for.
G
(PS - the "left side is compile-time and right side is run-time" is a very odd way to describe this sample. I can sort of see the abstraction the prof is reaching for - but I think this muddies the waters more than clears them...)
> These things may be obvious to you or I, but in a
> thread where the OP has explicitly said he
> does not understand why we use these abstractions, it
> is harmful to imply that Collection is a preferable
> abstraction to List, without exploring that further.
I don't only write for the OP. My post was written to convey that variables such as List should be properly encrapsulated. When data is properly encapsulated, then you can freely change implementation
without having to change the method signatures of the methods in question.
The List is properly encrapsulated below and accessed via get/set methods.
public class Buffer {
private List l = new ArrayList();
public List getBufferList() {
return this.l;
public void setBufferList(List x) {
this.l = x;
}
}
Desiging the class in this way is good OO design and a implementation of encapsulation.
A change to the implementation class, i.e.
private List l = new Vector();
is easily made. This is a fundamental cause of understanding
List list = new ArrayList();
> My sentence could have included the obvious, but that
> means extra key strokes.
>
> Personally, I prefer the following when it is
> suitable and when I don't have to use an index to
> find objects.
Are we to infer that "the following" refers to something that's "obvious," and therefore elided? Because it's not obvious, even to me.
Elided is a fancy word. I like it and prefer to use it when suitable :o)
