15-100 Lecture 15 (Friday, October 6, 2006)

15-100 Lecture 15 (Friday, October 6, 2006)

Today's Quiz

  //1. Please implement a class that achieves the following:


  //A. Models a Rectangle
  class Rectangle {
  
    // B. Maintains its length and width
    private double length;
    private double width;
   
   
   //C. Requires the length and width to be set when the object is created
   // This is called a constructor
   public Rectangle (double length, double width) {
     this.length = length;
     this.width = width;
   }
  
  
    // D. Provides methods to get each of the length, the width and the area
    //These are typically called getters
    public double getLength() {
      return length;
    }
    
    
    public double getWidth() {
      return width;
    }
    
    
    public double getArea() {
      return (length * width);
    }
  }
  
   public static void methodXYZ() {
    Rectangle rect = new Rectangle (1, 2);
    
    double area = rect.getArea();
  }

To String

There's one more method that will make our triangle complete and help a lot with testing, the toString() method. The toString() method gets called on everytime we say something like System.out.println(foo). If foo was an object, it would call the toString() method for that object. If we were to NOT write this toString() method within our Rectangle class, the Java compiler would successfully compile and run our code. The reason for this is that all classes in Java are assumed to extend the Object class, which is built into Java's API (the library of classes and methods that comes standard with Java and that the compiler automatically knows about). In brief, because our class is implicitly an extension of Object, it inherits a working method called toString().
However, because we have not specialized the toString() method to fit the details of our own Rectangle class, the toString() method will not print anything useful (it will print a barely intelligible collection of characters and numbers--which is the defination of the toString() method that it inherited). We can override the toString() method in Object by adding our own toString() method to our Rectangle class. The compiler will know to use ours instead of the inherited toString() method.
       public String toString() {
              return length + " x " + width;
       }
  


  More About Inheritence
  
  
  So what do you think of when you hear the word inheritance?  Money that you 
  receive from your parents as a birthright, maybe your genetic code. 
  Inheritance exists in Java too.  

  

  When a class is designed as a subtype of another class, by "extending" 
  the "base" or "parent" class, it inherits all of the parent class's methods.  

  


  All classes are a subclass of the class Object.  This provides a uniform 
  interface across all Objects and thus all classes. When you create 
  a class it automatically inherits several methods from the object class.

  

  Let's look at two methods in Object:

  

  

  class Object{
     public String toString(){
       //magic performed here
     }

     public boolean equals(Object o){
      //more magic performed here
     }
  }
  

  
  Now these two inherited methods aren't too useful in the grand scheme of 
  things.  The inherited equals() performs the == operation until you override 
  the method by writing your own version of it in the subclass you are working 
  on. (Don't remember what == does?  Look below for a refresher).

  


  The toString() is equally as useful. The inherited toString prints out 
  the name of the subclass and then a series of numbers and letters which tell 
  where the reference variable, holding the instance of the class you want to 
  go toString(), is pointing (aka where the object is being stored in the 
  computer's memory).  More commonly, it is appropriate for  the toString to
  provided critical information about our object's state.  (This usually 
  requires the method to return a String containing most of the information 
  that the object's instance variables are holding.)
  


  
  == and .equals()
  

  
  There's a big difference between == and equals().  A programmer needs to 
  know which comparison to use and when.  The == always does the same job.  
  It looks at the values that two variables are holding and returns a boolean 
  saying whether the two values are equal.  This works well enough for the 
  primitive types (such as int, double, char, long, etc.) since a variable 
  for a primitive holds the primitive's value.  However when you start using 
  the == operator with Objects (such as Strings) you need to remember that a 
  variable "holding" a String doesn't actually hold the String's value.  
  Instead they hold a reference to the String and where it is in the 
  computer's memory.  

  


  For this reason the line ("Hi"=="Hi"); would evaluate to false.  That line 
  makes two instances of a String that says "Hi".  Even thought the state
  of the Strings are the same the instances are different and thus == will say 
  that these two Strings aren't the same String. 

  

  So how do you compare two Strings to see if they have the same state or same 
  words "inside" of them?  That is what the .equals() is for.  It looks at the 
  Object's state and says whether the two states are the same.  

  

  Since the inherited .equals() for Objects uses the == comparison you can see 
  why it is useful to always redefine this inherited method.