Welcome to the CSC Q&A, where you can get help (and share your knowledge) about computer science!

Ignoring object types when writing a Comparator class

+14 votes
Why is it that we are willing to assume that the array being passed into the sort method is of the same data type as the Comparator? When writing a class that implements a Comparator the book does not consider the fact that an array of different type could have been passed in, eventually leading to an exception. They claim that we can assume the array is of the same type that we have written the Comparator for to avoid the exception. However, we spent the effort to check object types when writing .equals methods! It just feels unsafe, but I could just be paranoid.
asked Sep 8, 2015 in Fall 15-16 by Jeffrey Prior (100 points)

2 Answers

+6 votes
 
Best answer
The issue of ensuring that the data types of a collection match the data types required by a certain class (like a comparator) is a bit tricky in Java... and is solved by the use of "Generics".  e.g. new ArrayList<String>

The book is sidestepping around the issue of Generics... probably because it doesn't want to complicate the general design principles (which are sound) with another discussion of a (rather complex) Java language feature.

For example, ArrayList is a "generic" type in Java that can be "parameterized" by the type of data that it stores (in this case String).  

Similarly, the real Java library has Comparator be a generic type, that can be parameterized with the type of data that it compares as well.  So you'd have your concrete custom comparator class implement Comparator<String> and then it could sort String[]  (or if you wanted, List<String>).  And you could have another custom comparator that compared PotteryOrder objects that implements Comparator<PotteryOrder>.

I can't explain everything about Generics here, but it's easy to find more information online... just Google around!
answered Sep 10, 2015 by Forrest Stonedahl (3,438 points)
selected Sep 10, 2015 by Jeffrey Prior
That makes sense. Clearly a much more in depth issue that the book is not willing to delve into for our purposes. It just seemed too careless after we spent time and caution comparing objects in a .equals method. I may have to check it out. Thank you!
–1 vote
The book doesn't give the complete implementation of the comparator class, it gives the two, int and String and explains that we could add more methods for other data types. I realise that this may not be what you are asking but if you look at the example on page 69 the compare method takes the arguments Object; since every data type is an Object; it is the highest class of all the classes and all classes by default inherit the Object class. It takes the Object type and uses the instanceof to check what type of object it is, goes on to cast the other one and compare. The example in the book is just to indicate elegant software development, and expects one to borrow the skill and apply them to 'real' projects we are venturing into.
answered Sep 8, 2015 by Nelly Cheboi (100 points)
...