Sorting

[Angela D'souza]

Hi,
(1) I want to confirm the different between Comparator & Comparable interface.
Using Comparable: does only natural sort ordering
Using Comparator: besides natural ordering, does reverse & case insensitive ordering.
Am I right?
(2) Comparator has two methods : (i)compare() (2)equal() methods. what is difference between them?
(3) I have addressbook where I do sort by Name, Emailaddress & Company Name,for that first I put object(contains data like Name, Email & company name) in List,then use Collections.sort(List,SortEngine.FULLNAME) if i want to sort by Name and finally call SortEngine which has
public static final Comparator FULLNAME = new Comparator()
{
public int compare(Object o1, Object o2)
{
try
{
SortEngine name1 = (SortEngine)o1;
SortEngine name2 = (SortEngine)o2;
return name1.addFullName.compareTo (name2.addFullName);
}
catch(ClassCastException e)
{
// do something here
}
return 0;
}
};
For Comapany & Email I have other two static method in SortEngine. IS IT GOOD IDEA TO CREATE STATIC METHOD IN SORTENGINE FOR EACH COLUMN SORTING(like I have different static methods for Company,Email & Name)???
Thanks,
Angela

[Jim Yingst]

(1) I want to confirm the different between Comparator & Comparable interface.
Using Comparable: does only natural sort ordering
Using Comparator: besides natural ordering, does reverse & case insensitive ordering.
Am I right?
Mostly. Comparator can do just about any type of ordering you want, as long as you write the code for it. Reverse and case-insensitive ordering are two common examples. (You can also reverse a List easily with Collections.reverse(list).)
Also, note that when you implement Comparable, you are defining what "natural ordering" means for that class. For the String class it's already been defined to mean alphabetic order (well Unicode order really).
(2) Comparator has two methods : (i)compare() (2)equal() methods. what is difference between them?
The compare(Obje4ct, Object) method is the primary purpose of the Comparator - it compares two objects of some other class (not the Comparator). The equals(Object) method is generally less useful - it's just the equals(Object) method inherited from Object, but they put an extra restriction on it to make sure that if you override it, you do so correctly. The equals(Object) compares the Comparator itself to another object (presumably also a Comparator).
For example, if you've got a class Foo, you might also make a FooComparator class designed to sort Foo objects. The compare(Object, Object) would compare two Foo objects (and should throw a ClassCastException if the objects are not of class Foo). The equals(Object) method, if you bother to use it, will compare the FooComparator to another FooComparator. Usually this is only useful if you're planning to have multiple instances of the FooComparator class, and need to be able to store them in a Collection or something. Don't worry about it otherwise.
For Comapany & Email I have other two static method in SortEngine. IS IT GOOD IDEA TO CREATE STATIC METHOD IN SORTENGINE FOR EACH COLUMN SORTING(like I have different static methods for Company,Email & Name)???
Seems fine, although not really necessary. I mean, you're already making the Comparators public, so you can call
Collections.sort(list,SortEngine.FULLNAME)
almost as easily as some new method
sortByFullName(list);
But the latter may be a little easier to use, so if you want to code the method (which is very simple), why not?

[Angela D'souza]

Thanks Jim
But only thing I have confusion how I can use sortByFullName(list) and do sort by full name?
Thanks again,
Angela

[Michael Matola]

Here's what I think Jim had in mind:
void sortByFullName( List list )
{
Collections.sort( list , SortEngine.FULLNAME );
}
But since you've made FULLNAME public, clients can just as easily call
Collections.sort( list , SortEngine.FULLNAME );
themselves as they can call sortByFullName( list );

[Ilja Preuss]

Originally posted by Michael Matola:
Here's what I think Jim had in mind:
void sortByFullName( List list )
{
Collections.sort( list , SortEngine.FULLNAME );
}
But since you've made FULLNAME public, clients can just as easily call
Collections.sort( list , SortEngine.FULLNAME );
themselves as they can call sortByFullName( list );

OTOH, it would be bad to spread the latter over your client code. It'd be a very good idea to encapsulate the call to Collections.sort - just imagine what happened if you later wanted to change the sorting algorithm.

[Marilyn de Queiroz]

Originally posted by Ilja Preuss:
OTOH, it would be bad to spread the latter over your client code. It'd be a very good idea to encapsulate the call to Collections.sort - just imagine what happened if you later wanted to change the sorting algorithm.

I agree if you are going to use Collections.sort more than once or if you do decide to change the sorting algorithm.

[Ilja Preuss]

Originally posted by Marilyn de Queiroz:

I agree if you are going to use Collections.sort more than once or if you do decide to change the sorting algorithm.

Well, typically you don't know in advance wether you will want to change the algorithm later, do you?
Additionally, I typically find such methods to have the benefit of better communication to the reader. YMMV.

[Jim Yingst]

I agree with Ilja. However if we provide public static methods like this, and want to allow for the possibility of changing the algorithm later, there's no real reason to also make the Comparator FULLNAME public as well. The public API needs one or the other, not both. Unless there's other code that needs a Comparator rather than a static method - in which case, you'll have a harder time changing algorithms later.