Java Collections #1

I know its kind of weird to DIRECTLY start with java collections, since it is considered as an advance topic in Core Java. So beginners in Java or newbies might get a little uncomfortable while reading this post. Apologies for that ! I will try to make this as simple and easy and comfortable (... :) ...ha ha !) as possible. To remind you.....yes you ! .....dear Reader ! ... these are only my observations and findings. So my posts are open for discussions. Java Collections:- The guys who developed this awesome technology, ...i guess they were quiet smart enough to create a separate package to contain collections. I mean the idea to create this, came out of the need for ready to use codes for storing data (...well known as data structures.) They must have written a lot of programs for data structures like Linked list, Array list, Hash Map etc., ...and that too with many functionalities like sorting, adding , searching etc., Of course, these functionalities are required when you work with data structures. So this package => "java.util" contains all the classes and the interfaces that are required to work with the collections package. Classes representing data structures like arrays, lists, trees, sets, are a part of the collection framework. In other words the classes that provide these data structures belong to the family of Collection .... "Collection" interface, therefore is the first and the only ancestor of this family. Following is the family tree that represents Collections family :-



It can be seen from the above diagram that, "Collection" is the top-most parent of the family. The major implementations like "ArrayList" , "Vector", "LinkedList" ...etc., are the children of "Collection" interface. Let us understand this hierarchy first. The children at the first level are "List" and "Set". These are also interfaces, and hence are not concrete implementations. Since, "List" interface is the child of the "Collection" interface ... using the OOPS language we can also say that "List" is A "Collection".

List:-
List is A Collection
List is an ordered Collection
That means the elements are inserted one after another sequentially.
It allows duplicate elements to be inserted in the collection.

Set:-
Set is A Collection
Set cannot contain duplicate element.
Set allows at the most one null element only.
The Set does not have a specific implementation like the List has (...ordered collection)
Set can be implemented as a Tree or HashTable also! (Tree and HashTable are also data structures but little more complex compared to linked list, array list etc.,)

Now, since these are only the interfaces, implementation wise they are void... i.e., these interfaces only describe the contract that all the implementing classes must honor. These interfaces do not provide any implementation or logic related to that data structure. Now in order, to traverse through ordered collection like "List" they have also provided controls, like "Iterator". Using "Iterator" interface or the child of "Iterator" (...known as "ListIterator") we can safely access the elements in the "List" or any of its implementations.

Now, the top most parent "Collection" interfaces has given pure abstract contracts that must be implemented by any class that implements this Interface. Let us take a look at these contracts that are mostly required when we work with collections :-

add(Object o)
addAll(Collection c)
clear()
contains(Object o)
containsAll(Collection c)
remove(Object o)
removeAll(Collections c)
retainAll(Collection c)
size()
toArray()
toArray(Object[] o)

Majority of these contracts are implemented in the concrete classes that implement the "Collection" interface. For example, we will see the implementing classes like "ArrayList" , "Vector", "LinkedList".

ArrayList:-

add(Object o)
addAll(Collection c)
clear()
contains(Object o)

remove(Object o)

size()
toArray()
toArray(Object[] o)

As you can see majority of the contracts that the "Collection" Interface mentions are honored by the "ArrayList" class. Implementations for contracts like (containsAll(), removeAll(), retainAll() are not honored! ). Let us take a look at other class, "Vector".

Vector:-
add(Object o)
addAll(Collection c)
clear()
contains(Object o)
containsAll(Collection c)
remove(Object o)
removeAll(Collections c)
retainAll(Collection c)
size()
toArray()
toArray(Object[] o)

All the contracts are honored by this class ! :) .... Vector is pretty honest and humble it seems ! :) Now, take a look at the class => LinkedList

LinkedList:-
add(Object o)
addAll(Collection c)
clear()
contains(Object o)

remove(Object o)

size()
toArray()
toArray(Object[] o)

As can be seen, even LinkedList honors majority of the contracts that the "Collection" interface has mentioned.

Thus, by now it must have occured to you, how intelligently the Java guys have designed this package. Imagine this situation, you like Vectors a lot ! ... because of its dynamically growing quality and easy to add elements functionality. And lets say you also want the elements to be arranged and linked sequentially as a linked list, in that case, you can create a vector,... go on adding elements into it and pass it as a "Collection" to an empty "LinkedList" object using the function addAll(Collection c) function. Isn't it great ! This is where you will get to see the MAGIC OF INHERITANCE and POLYMORPHISM.

So, even if you know certain contracts that i have mentioned above, you can work with any damn implementaion of the Collection interface since it will somehow have to honor those contracts.

I think this is sufficient for today. In the next post i will discuss about some classes and few programs that i have worked upon.

Till then have a good day ....dear Reader ! :)

Thanking you
Omkar Patkar