Outline of Class 36: Comparable Objects

Miscellaneous

• Just a reminder that there's no class on Tuesday.
• Don't forget to read chapter 11 for Monday.
• Those of you who have signed up for the independent study (or indicated interest) can find your names at http://www.math.grin.edu/~rebelsky/Courses/397/98S/students.html
• Those of you interested in the job should take the test at http://www.math.grin.edu/~rebelsky/Glimmer/programmer.html
• There will be some more delays on the grading. Sorry, this has been a hellish term.

Comparable Objects

• In a number of previous classes (or at least the notes for the classes), I've referred to "comparable" objects, and have used a number of methods to support them.
• Let's spend a little time thinking about the meaning of this in more detail.
• In effect, a comparable object is one which we can compare to other objects. What are normal comparisons?
• To some, equality is the only neccesary comparison.
• Java provides two forms of comparison for equality for objects
  • == compares two references to see that they refer to the same object
  • equals() compares two references to see if the objects they refer to are somehow equivalent. It is your responsibility to write this method for your own classes.
• How do we define our own equals()? Well, it depends on our class, since different classes will have different notions of equality.
  • In our Fraction class, we'd like the numerator and denominator to be the same.
  • In a Position class, we'd like all the components to be the same.
• But there are also some general Java issues to consider. The first is what the parameter type of equals() should be.
• One possibility is the same type as our class, and we should certainly define that equals()
• However, there are also reasons to use a more general class (i.e., a superclass of our class). Why? Because objects in our class may occasionally be treated as more general objects (e.g., when we're searching through a list of Objects).
• So, what do we do in that case?
  • We determine whether that object is actually a an object in our class. How? By using the instanceof operator.
  • If it's in a different class, it's probably different (depending on our notion of equality).
  • If it's in the same class, we can use our other equality.
• A simple example may help. Consider equality for points.

  /** A two-dimensional point in a discrete space. */
  public class Point2D {
    /** The x coordinate */
    private int x;
    /** The y coordinate */
    private int y;
    ...
    /**
       Compare another point to the current point.
       pre: (none)
       post: true is returned if they are the same; false o/w
     */
    public boolean equals(Point2D compare_to) {
      return (x == compare_to.x) && (y == compare_to.y);
    } // equals
    /**
       Compare another object to the current point.
       pre: (none)
       post: true is returned if the other object is a point and
             is the same point; false o/w
     */
    public boolean equals(Object compare_to) {
      if (compare_to instance_of Point2D) {
        return equals((Point2D) compare_to);
      }
      else return false;
    } // equals
  } // Point2D
  

• This suffices for equality. However, what should we do about other comparisons, such as those needed for sorting?
• In some sense, a simple lessThan() method may suffice.
• How do we write functions that work on all objects that supply this method?
  • By making a Comparable class, and requiring that all classes that supply lessThan() extend Comparable. But what if we want to extend another class, too?
  • By making a Comparable interface.
• Are there other methods that should be in our Comparable interface? Arguably, no ...
  • equals() is supported by all objects.
  • lessEqual() can be written as a hybrid of lessThan() and equals()
  • greatherThan can be written as !lessEqual()
• However, there are systems in which those implications are not true (as our mathematician students will tell us).