This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Ravi Kiran V wrote:Thanks Stephan ,
that was a valuable information .
You mean to say that we must use Comparable interface to sort in a natural order only ??
Thanks in advnace .
What he means is that the Comparable interface defines the natural order, and Comparator provides a means of sorting objects in a different way than the natural order, or for sorting objects that do not have a natural order (do not implement the Comparable interface).
For example, books. Perhaps the 'Natural Order' for ordering books is through the Dewey Decimal System. If you were defining a book you would make it implements Comparable and the compareTo method would use the two books' Dewey Decimal index for sorting. But let's say later you want to sort by title, or by Author's last name... that is the job of a Comparator.
That's what Comparable is for. But what if you want to sort in two ways?
Suppose I make it implement Comparable<Employee> based on the name. But now I want to sort all my employees based on how long they've been employed. That's what Comparator is for.
Comparator is also for classes you can't change but don't implement Comparable, like java.awt.Color. I can't change it, but if I want to sort them (on RGB values) I can create a Comparator<Color>.
Ravi Kiran V wrote:But when we implement the Comparable interface and override the compareTo method , cant we redefine the sorting order based on the return type of compareTo method ??
Yes, and whatever you define in the Comparable's compareTo becomes the Object's natural order. But if you wanted to sort different ways you would need multiple implementations. If you only had the Comparable interface, then you would need multiple classes, each with a different definition of the compareTo method:
Then you have to be able to convert between them when you want to sort the same books different ways etc... it won't be easy.
Instead, you want just one class:
And have different ways of sorting them (Comparators):
Then you have a much simpler structure - a single book class which handles the 'natural' order, and utility Comparators which handle other sorting routines. No need to change Book or subclass it or anything...
Same thing in a different way we can look suppose in a given scenario you have a Employee class but you don't have the source code or may be you don't have the permission to change any code but still you may need to sort it say by id or age or any other property. At this point using comparator is always useful keeping the code intact. That is the new code will not affect the existing one.
It's more a matter of concept than practical results. In practice, you *can* just use Comparator to provide different sorting orders for the same class. However, some classes in concept have a natural, or default, order.
For instance, say you want to print the cast of a movie. Let's just say that actors have a natural or default order, namely alphabetical by name. You can implement the compareTo() method of an actor in such a way that the cast will be sorted this way.
However, some movies sort the actors by order of appearance. You can now provide a separate Comparator to do this, and still keep the default functionality. As a matter of fact, you would probably need a Comparator to do this, because an Actor can't decide where in the movie it appears, unless the Actor keeps a reference to the movie. A movie on the other hand, could provide a Comparator that sorts its actors in this fashion. Here is the full example: