Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (489)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (555)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Problem with Comparator interface  (Read 1027 times)
0 Members and 1 Guest are viewing this topic.
Offline King_of_Men

Senior Newbie




EUII player


« Posted 2005-03-28 23:58:41 »

I have a class called Module, which often needs to be sorted by priority. I therefore make it implement the Comparator interface, thus :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public int compareTo (Module d) {
      System.out.println("Comparing better");
      if (priority > d.priority) return -1;
      if (priority < d.priority) return 1;
      return 0;
}


public int compareTo (Object d) {
      System.out.println("Comparing boring");
      return 0;
}


Unhappily, the prints indicate that it is the second, default method that is being called when I ask for sorting of an array of subclasses of Module. I didn't have this problem before I created the subclasses, so I'm reasonably sure this is the cause.

I tried making a compareTo method for each subclass, but it is still the generic method that is called. Does anyone have a good solution?

To win one hundred victories, in one hundred battles, is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
Offline Daire Quinlan

Junior Member





« Reply #1 - Posted 2005-03-29 07:53:30 »

are both the methods above implemented in module ? Try just implementing the method that takes Module as an argument, and not the one that takes Object. A subclass will pick up the most general method first that matches the method signature its looking for. So you can remove the second one entirely, or have the subclass also override the method.

D.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #2 - Posted 2005-03-29 09:15:03 »

Your first method with never be called by a routine that uses a Comparator.  If you look at the Comparable interface, you will see that the method signature is the same as your second method.  This is the one that will always be called.  So if you have a super class that implements the Comparable interface, then all you have to do is have your subclasses override the compareTo(Object) method(as Daire said).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Daire Quinlan

Junior Member





« Reply #3 - Posted 2005-03-29 10:05:27 »

oh, and thats the Comparable interface, not the Comparator interface. I presume it was just a typo on your part, as you would have got compile time errors instead of bugs :-)

Also a bit of a brainmush on my part, I'd forgotten you couldn't override interface declarations like that. As CaptainJester said, you gotta use the same method declaration as in the interface, then cast to your particular circumstance, so your code will look something like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public int compareTo (Object d) 
{
    Module m = (Module)d;

    System.out.println("Comparing better");
    if (priority > m.priority)
        return -1;
    else if (priority < m.priority)
        return 1;
    else
        return 0;
}
Offline King_of_Men

Senior Newbie




EUII player


« Reply #4 - Posted 2005-03-29 17:12:35 »

Comparable, right you are. I found the thing that was confusing me : My testing algorithm was a bit flawed, so it looked like it was working before I introduced the subclasses. In fact it wasn't.  Smiley

Thanks for the replies. I'm not happy with the casting, though; I like to avoid that when I can.  Sad

To win one hundred victories, in one hundred battles, is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #5 - Posted 2005-03-29 19:26:33 »

Daire's method is a bit off.  Here is what you should do.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public int compareTo (Object d)  { 
  int result = 0;

  if(d instanceof Module) {
    Module that = (Module)d;
 
  if (this.priority > that.priority)  {
    result = -1;
  }
  else if (this.priority < that.priority)  
    result = 1;
  }
  else {
     result = 0;
  }

  return result;
}  

You should first check to make sure that the Object is of the right type.  Then you can safely cast it.

Offline Daire Quinlan

Junior Member





« Reply #6 - Posted 2005-03-29 20:09:54 »


oh right, did we decide eventually that we didn't like multiple returns in the one method ?? :-)

To be honest, though I suppose the instanceof is neccessary for robustness sakes, I wouldn't normally include it for a comparable implemented class. You're very rarely in the situation where some collection is going to be filled with a bunch of objects that aren't extended from a particular sub object, or all implement a particular interface.

D.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #7 - Posted 2005-03-30 00:12:55 »

Quote

oh right, did we decide eventually that we didn't like multiple returns in the one method ?? :-)

Nah, that's just the way I like to do it.  Grin
Quote

To be honest, though I suppose the instanceof is neccessary for robustness sakes, I wouldn't normally include it for a comparable implemented class. You're very rarely in the situation where some collection is going to be filled with a bunch of objects that aren't extended from a particular sub object, or all implement a particular interface.

D.

Yeah, the chance is minimal, but you should always program for robustness from the start.  It is easier to than spotting a bug.

Offline ap_kelly

Junior Member




Java rocks!


« Reply #8 - Posted 2005-03-30 00:35:44 »

If the parameter passed in isn't an instance of Module you should really throw an IllegalArgumentException. There is no point in sorting a list of objects only to find that in the middle of the list is a group of objects that you aren't interested in.

This problem kind of goes away when you start to use the following code in Java 5.0

List<Module> myList = new ArrayList()<Module>;

Andy.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (9 views)
2014-08-31 22:59:12

TehJavaDev (22 views)
2014-08-28 18:26:30

CopyableCougar4 (27 views)
2014-08-22 19:31:30

atombrot (40 views)
2014-08-19 09:29:53

Tekkerue (38 views)
2014-08-16 06:45:27

Tekkerue (34 views)
2014-08-16 06:22:17

Tekkerue (24 views)
2014-08-16 06:20:21

Tekkerue (34 views)
2014-08-16 06:12:11

Rayexar (71 views)
2014-08-11 02:49:23

BurntPizza (47 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!