Sorting

Angela D'souza

Ranch Hand

Posts: 469

posted 14 years ago

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

Wanderer
Sheriff

Posts: 18671

posted 14 years ago

(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?

"I'm not back." - Bill Harding, Twister

Angela D'souza

Ranch Hand

Posts: 469

posted 14 years ago

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

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.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Marilyn de Queiroz

Sheriff

Posts: 9082

12

posted 14 years ago

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.

JavaBeginnersFaq"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt

Ilja Preuss

author
Sheriff

Posts: 14112

posted 14 years ago

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.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Jim Yingst

Wanderer
Sheriff

Posts: 18671

posted 14 years ago

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.