The Collections Framework
|Make appropriate selection of collection classes/interfaces to suit specified behavior requirements.|
As far as I can gather, and this is implied by the objective itself and the sample examination question on the Sun website,
this objective just requires a general knowledge of the classes/interfaces, in other words which to use for a given purpose.
If you want a more in-depth treatment of the subject, try the Sun tutorial:
A Set is a collection which cannot contain any duplicate elements and has no explicit order to its elements
(unlike, for example, an array, where every element exists at a particular index i.e.
A SortedSet is a Set which maintains its elements in ascending order.
A List is a collection which can contain duplicate elements, and the elements are ordered (like an array, you can add an element at a specific position, and the elements are accessed using their index).
[Stack has come up in the examination in the past, so here is some info. on it.
Stack is a subset of Vector, which contains some extra methods. The idea of a stack is like its name, it acts like a piled up stack of items: When you add an element, it goes to the top of the stack, and when you extract an element, it is taken off the top. In other words, this is a last-in, first-out system. The methods are:
push(object) - Add an element onto the top of the stack.
pop() - Removes the object at the top of this stack and returns that object as the value of this function.
peek() - Looks at (i.e. returns) the object at the top of this stack without removing it from the stack.. ]
Maps keys to values. In other words, for every key, there is a corresponding value, and you look up the values using the keys. Maps cannot have duplicate keys, and each key maps to at most one value.
Note: A Map does not implement the Collection interface.
A SortedSet is a Set which maintains its mapping in ascending key order.
Implementations of the SortedSet and SortedMap interfaces sort their elements. To determine what criterion is used to sort the elements you can use either the Comparable or Comparator interfaces. Using Comparable means that the classes that you put in your SortedSet or SortedMap implement the Comparable interface, which just means that they contain a method compareTo() which determines whether the object is "greater" or "less than" another object. To use the Comparator interface, you pass an object which implements Comparator to your SortedSet or Sorted map, and it will use the Comparator for ordering.
For completeness, here is some information on BitSet, which isn't part of the Collections Framework, but may be examinable:
A BitSet contains elements which are bits, i.e. of the boolean primitive type. Like, for example, a Vector, and unlike an array, a BitSet does not have a fixed size, and grows as needed when you add elements to it.
|Distinguish between correct and incorrect implementations of hashcode methods.|
The hashcode value of an object gives a number which can be used to in effect to 'index' objects in a collection.
A collection class can group its objects by their hashcodes, and if you called e.g.
case of a Map), it can first
find the group based on the hashcode, then search that group. This avoids the need to check every object in the collection.
The requirements of a
hashCode() implementation are that if two objects are equal as determined the
method, their hashcodes should be the same. This is why wherever you override the
equals() method, you should
The reverse is not required i.e. it is permitted for two objects that are not equal to have the same hashcode. This makes
it is not always possible to ensure unique hashCodes. The method returns an
int and there are only an finite number
int values to use. However, where possible, it is desirable to have the hashcodes be distinct as this can improve
performance. If the hashcodes can be well distributed (i.e. scattered throughtout the
int range) aswell, all the better.
©1999, 2000, 2002 Dylan Walsh.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being the disclaimer, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".