Outline of Class 17: Comparable Objects

Held: Monday, February 16, 1998

Administrivia

• Don't forget today's noontime brown-bag CS lunch. I believe today is Multimedia on Ethernet.
• For tomorrow, read chapter 4 of Bailey.
• There was a typo on assignment 4. I was one week off in the due date.

Comparable Objects

• In many of the algorithms that we write, we end up needing to compare two objects. Why?
  • In using dictionaries, we need to know whether a key matches a previously inserted key.
  • In searching algorithms, we often need to be able to know whether a value is less than or greater than another value.
  • ...
• Note that there are a variety of types of comparisons we do
  • Are two objects equal?
  • Is one object smaller than another? Larger than?
  • Does it even make sense to compare two objects?

Do Comparisons Always Make Sense?

• One particularly difficult question is whether it makes sense to compare two objects, even when those objects support comparison operations.
• For example,
  • Should we compare an Integer to a Float? (Probably yes)
  • Should we compare an Integer to a String? Probably not, unless we wanted to convert the Integer to a String.
• We can enforce some of this using parameters. For example, we might write a compare method for Integer that only takes Integers and Floats as parameters.
• However, some of the time we'll need to write more general methods. For example, equals is supposed to take an Object as a parameter.
• What is the solution? There are a few.
• Java supports the instanceof operation, of the form
  object instanceof class
  It holds true when the object is an instance of that class (or a subclass of that class). This should be your standard method for checking whether a comparison makes sense.
• Java allows you to try to coerce objects from one type to another by prefacing the object with a parenthesized class name. For example,
  (String) alpha
  tells Java to treat alpha as a string, even if it didn't know that alpha was a string.
• However, if Java can't do a reasonable coercion (e.g., from String to Integer), it throws a ClassCastException.

Equality

• As you've noted, Java provides one core form of comparison, an equals method that is implemented by Object and that most classes are expected to override.
• We've already seen a standard mechanism for writing equals
  • Write a variant of equals that takes a "reasonable" type as a parameter.
  • Write a more general equals that tests the type of the object and calls the more reasonable equals when necessary.
• For example,

  public class Sample
  {
    /**
     * The only attribute of this class.
     */
    int info;
  
    /**
     * See if another Sample is equivalent to this one.
     */
    public boolean equals(Sample other)
    {
      return other.info == info;
    } // equals(Sample)
  
    /**
     * See if another object is equivalent to this Sample.
     */
    public boolean equals(Object other)
    {
      if (other instanceof Sample) {
        return equals((Sample) other);
      }
      else {
        return false;
      }
      // This could be written more concisely as
      //   return ((other instanceof Sample) && equals((Sample) other))
    } // equals(Object)
  } // Sample
  

A Comparable Interface

• Since we'll want to work with a variety of comparable objects, it makes sense to design a generic interface for comparable objects, and then have our objects implement that interface.
• Are there other strategies? Yes. You might choose to do comparison on a case-by-case basis.
  • Java provides a compareTo method in java.lang.String
  • However, the use of a class-specific method rather than an interface makes it more difficult to write general functions that work with any kind of object that can compare itself.
• What belongs in the interface?
  • A less-than method?
  • A greater-than method?
  • An equals method? (Does the built-in one suffice?)
  • A not equals method?
  • A more general compareTo function like Java uses?
• Given that many of these can be formed from others, how many do we really need to support? This is a design decision that we need to think for a while about.
• For now, we'll just support lessThan.
• Are there design issues for this function? Certainly ...
  • What pre- and post-conditions do we need?
  • What should the type of the parameter be?
  • Will it throw any exceptions?
  • ...
• Here's my version. Your version may differ.

  /**
   * An interface to support objects that we can compare.
   *
   * @author Samuel A. Rebelsky
   * @version 1.0 of February 1998
   */
  public interface Comparable
  {
    /**
     * Determine whether the current object is less than the parameter.
     * <br>pre: The other object is of a "reasonable" class (one we
     *        can reasonably expect to compare to the current object).
     * <br>post: Returns true if the current object (this) is less than the
     *         the parameter (other).  Returns false if the current object
     *         is equal to or greater than the other object.
     *
     * @exception IncomparableException
     *   When the other object cannot reasonably be compared in this manner.
     */
    public boolean lessThan(Comparable other)
      throws IncomparableException;
  } // Comparable
  

Comparing Complex Numbers

• Can we rework our Complex class to support our new interface?
• Yes, but it does require us to think somewhat about what it means for one complex number to be smaller than another complex number.
• One reasonable metric would be the radius; another would be the angle.
• Using the radius,

  /**
   * Determine whether the current complex number is less than the parameter.
   * Uses distance from the origin of the "point" corresponding to the 
   * complex number as the metric for comparison.
   * pre: The parameter is a complex number.
   * post: Returns true if the current object (this) is less than the
   *       the parameter (other).  Returns false if the current object
   *       is not less than the other parameter.
   *
   * @exception IncomparableException
   *   When the other object is not a complex number.
   */
  public boolean lessThan(Comparable other)
    throws IncomparableException
  {
    if (!(other instanceof Complex)) {
      throw new IncomparableException("Can't compare a Complex to a " +
        other.getClass());
    }
    return lessThan((Complex) other);
  } // lessThan(Comparable)
  
  /**
   * Compare two Complex numbers according to the description given
   * above.
   */
  public boolean lessThan(Complex other)
  {
    return this.getRadius() < other.getRadius();
  } // lessThan(Complex)
  

• Note, however, that this sense of comparison leads to an interesting situation. We can have two complex numbers, A and B, such that
  • A is not less than B
  • B is not less than A
  • A does not equal B
• Is this a problem with our implementation of lessThan or our assumptions in designing the Comparable interface?