How to compare Classes and Inherited Classes in Java

I have two classes - Task (which implements Comparable) and DeadlinedTask (where DeadlinedTask extends Task). And for each of them I have written an overloaded compareTo function (each has compareTo(Task) and compareTo(DeadlinedTask)).

The idea is that I can sort normal Tasks by category, and DeadlinedTasks by deadline, but I also want all of the DeadlinedTasks to be sorted above the Tasks.

When I call Collections.sort(myListOfTasks) on a list of only Tasks (no DeadlinedTasks), everything works like a charm. However when I have a list of both Tasks and DeadlinedTasks, the objects change order, but they are not fully sorted.

I have tried returning numbers other than 1 on the interclass compares (1, 1000, 1000000 all did the same thi开发者_开发技巧ng). Is there any way to do this through compareTo and Collections.sort, is there a different java functionality I can use, or do I have to write my own search function (as a Comparator?)?

Task compareTo Methods:

public int compareTo(Task other){
    if(this.GetCategory().compareTo(other.GetCategory())==0)
        return this.GetName().compareTo(other.GetName());
    else 
        return this.GetCategory().compareTo(other.GetCategory());
}
public int compareTo(DeadlinedTask other){
    return 1;
}

DeadlinedTask compareTo Methods:

public int compareTo(Task other){
    return -1;
}
public int compareTo(DeadlinedTask other){
    if(this.GetDeadline().compareTo(other.GetDeadline())==0)
        return this.GetName().compareTo(other.GetName());
    else 
        return this.GetDeadline().compareTo(other.GetDeadline());
}

Thanks for any help

... or do I have to write my own search function (as a Comparator?)?

Yes. I think that's the best way.

The normal way to handle equals and compareTo is to return false (for equals) or throw ClassCastException (for compareTo) if the arguments actual type doesn't match the actual type of this.

If you try to implement equals or compareTo for subtypes, you can easily create semantic anomalies such as:

• a.equals(b) and b.equals(a) returning different values, or
• a.compareTo(b) and b.compareTo(a) returning inconsistent values.

Avoiding those anomalies would entail making the supertype aware of the subtype. That is a bad from a design perspective because it restricts your ability to create more subtypes in the future.

For use-cases where you need to implement a rule that orders instances of two or more different classes, a Comparator is the best solution.

Per class, only one compareTo method can be used to implement the Comparable interface. If you use Comparable without generics, then this is

public int compareTo(Object o)

If you're using generics, e.g. Comparable<Task>, then it's

public int compareTo(Task o)

Your compareTo(DeadlinedTask o) method will be ignored concerning the Comparable<Task> interface. It just "accidentally" has the same name, but it's an independent overloading.

(By the way, it's not possible to implement both Comparable<Task> and Comparable<DeadlineTask>).

So what you'll have to do instead, is change your Task.compareTo(Task o) method to use instanceof (it has to use runtime information after all). I agree with Stephen, that it would even be better to write a Comparator.

Comparable defines a natural order for all instances of a class. So if DeadlinedTask should always come before Tasks, then the compareTo method should implement it.

You should not redefine compareTo in DeadlinedTask, because this would break the contract of anti-commutativity : if (t1.compareTo(t2) > 0), then t2.compareTo(t1) < 0.

I would thus completely avoid to implement Comparable in the Task class, and use a dedicated comparator when sorting a collection of tasks. If you really want your task to implement Comparable, than you need to make its implementation depend on the existence of DeadlinedTask (which is not very OO) :

public class Task implements Comparable<Task> {
    // ...
    public final int compareTo(Task t) {
        if (this instanceof DeadlinedTask) {
            if (t instanceof DeadlinedTask) {
                return ((DeadlinedTask) this).getDeadline().compareTo(((DeadlinedTask) t).getDeadline());
            }
            else {
                return -1;
            }
        }
        else if (t instanceof DeadlinedTask) {
            return 1;
        }
        else {
            return this.category.compareTo(t.category);
        }
    }
}

Note that Java uses a lower-case letter at the beginning of methods (getDeadline(), and not GetDeadline()), and that you don't need to use getters to access private properties of your own class.

In addition to what StevenC have said, if you know in advance that you will have a hierarchy of value objects, you can check whether the class of the argument of the compareTo() method is a subtype of the class of the object and if yes, reverse the comparison, so you will always have the child comparing against the parent:

public boolean compareTo(Object o) {
  // check for null
  boolean isSubtype = getClass().isAssignableFrom(o.getClass()) && getClass()!=o.getClass()
  if (isSubtype) return -((/*cast to this type*/) o).compareTo(this);
}

This way, the comparison remains consistent and the base type does not to be aware pf each individual subtype, but just that subtypes exist.

Yes it seems a comparator is the simplest (& cleanest way) But you can simply delegate te bulk ot the work to the compareTo(...) methods you have already written, all you really need to add is code to handle comparison between the sub and super classes:

public int Compare(Task t1, Task t2) {

    if (t1 instance of DeadlinedTask && !(t2 instanceof DeadlinedTask))
        return 1;
    else if (t2 instance of DeadlinedTask && !(t1 instanceof DeadlinedTask))
        return -1;
    else
        return t1.compareTo(t2);
}

but it just occured, how are you declaring the classes? do you include Comparable in the implements clause of the Task class and visa versa? if not, then perhaps when the lhs object is a Task, then only compare(Task) gets called ?? otherwise you need to have both in the implements clause ie:

class Task implements Comparable<Task>, Comparable<DeadlinedTask>

The magnitude of the value returned will not change anything, ie returning 1 and 1000000 is exactly the same, as tests are only < 0, > 0 and == 0 (this contract IS specified in the docs for the Comparator interface. I used to tell students trying to remember what return values mean, to imagine comparing ints, then we could just write:

int compare (int a, int b) { return a - b; }