| << Chapter < Page | Chapter >> Page > |
| Listing 3 . The Populator class. |
|---|
class Populator{
public static void fillIt(Collection ref){ref.add(new Integer(4));
ref.add(new Integer(4));ref.add(new Integer(3));
ref.add(new Integer(2));ref.add(new Integer(1));
}//end fillIt()}//end class populator |
As you can see in the above fragment, the fillIt method receives the reference to the TreeSet object as type Collection . This method doesn't know, and doesn't care, what the actual type of the object is. All itcares about is that the object is a Collection object. (Otherwise, the object's reference couldn't be passed in as a parameter. A type mismatch would occur.)
Because the incoming parameter is a reference to a Collection object, the fillIt method can call the add method on the object with confidence that the behavior of the add method will be appropriate for the specific type of object involved. (For example, the behavior of the add method for an object of the TreeSet class will probably be different from thebehavior of the add method for an object of some other class that implements the Collection interface.)
The great thing about polymorphic behavior is that the author of the fillIt method doesn't need to be concerned about the implementation details of the add method.
The code in the fillIt method adds five elements to the object. Each element is a reference to a new object of type Integer . Two of the objects encapsulate the int value 4, and thus are duplicates.
The int values encapsulated in the Integer objects are not in ascending order. Rather, they are added to the object in descending order. (They could be added in any order and the end result would be the same.)
The add method for the TreeSet object filters out the duplicate element in order to satisfy the contract of the Collection interface.
In this case, the author didn't care what happens in the case of duplicate elements. If the author of the fillIt method does care what happens in the case of duplicates, she can find out when an object is a duplicate.
According to the contract of the Collection interface, the add method must return true if the call to the method modifies the contents of the object and must return false if the collection does not permit duplicates and the collection already contains the specified element.
Even though the elements are passed to the add method in descending order (or could be passed in any other order), they are stored and maintained in the TreeSet object in such a way that they can later be accessed in ascending order.
When the fillIt method returns, the TreeSet object contains four (not five) elements with no duplicates. Each element is a reference to an object of type Integer . Those references are maintained in such a way as to make them accessible in ascending order, based on the int values encapsulated in each of the Integer objects.
Returning now to the doIt method in the Worker class that was called in Listing 1 , the statement in Listing 4 calls the iterator method on the TreeSet object's reference that is stored in the reference variable of type Collection .
Notification Switch
Would you like to follow the 'Object-oriented programming (oop) with java' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|