CSC153 2004S, Class 38: Inheritance

Admin:
* Pick on the prospie.
* Yet another chapter to read.  Yay!  (O3, Polymorphism)
* Questions on homework 5?
  * What happens if someone tries to create a rational number with a denominator of zero?  
    * In the Rational class: Throw an exception
    * In the calculator: Print a sarcastic error message
  * Unclear on using the registers:
    * They're basically simple variables in a really simple programming language
  * What about the unnamed register?
    * That's where all the action happens
  * What's the difference between code reuse and plagiarism?
    * If I provide you with a class, you can reuse it and summarize changes.
    * If you find code, you can reuse it and summarize changes.
* New homework: HW6 (a raquetball simulator) (due Wednesday)
  * Do we have to get input from the user?
    * Yes, either interactively or via the command line.
* Exam 3 to be distributed Monday. (due following Wednesday)

Overview:
* Reuse.
* Inheritance.
* Inheritance in Java.
* Special issues: 
  * Constructors.
  * Interfaces.
  * Abstract Classes.
* Lab.

Why should the prospective named Gil come to Grinnell rather than Rice or UTAustin/Honors
* Grinnell is small.  Bzzz..  So is UTAustin/Honors.
* We grow a grain (corn).  Bzz ... Rice is named after a grain.
* After you watch Children of the Corn, you'll never leave your dorm and therefore be much more likely to get real work done.
* Fun with prospies.
* Wants to do Math, CS, and/or Literature.
  * Grinnell is supportive of joint departments.
* If you go to UTAustin, you might meet a friend of Arjun Guha.

Inheritance: Build one new class based on another
* Why?  Saves time.  You don't need to rewrite the code that's the same.
  * Why is that better than copy and paste?
    * Similar to real life.  We like Aristotle's theories on the classification of the world.
    * Less code!  "Prettier" because you get to make cool pictoral graphs.
    * Easier to fix errors!  Only one place to change it.
    * Somewhat encapuslated.  You don't need to know how a class works in order to create a subclass.
  * Changes propagate.  If you need to change a base class, all of its subclasses automatically change.
  * Supports polymorphism

In Java, inheritance is "easy"

public class Subclass
  extends Superclass
{
} // class Subclass

Almost all the methods available to superclass are available to subclass.
Almost all the fields available to superclass are available to subclass.

Encapsulation suggests that some might be unavailable.
* protected and public are okay for subclass use
* private are not okay for subclass use
* "package" are okay only for subclasses in the same package

Problems and other aspects of inheritance

Writing constructors of subclasses can be "interesting".
* For example, how do private fields get initialized?
* Solution: Every constructor of the subclass must call a constructor of the superclass, explicitly or implicitly.
  * If you don't explicitly call the constructor of the superclass, the zeroary constructor is called.  (If the superclass has no zeroary constructor,you must explicitly call the constructor.)
  * The call to the superconstructor must be the *first* instruction in your subconstructor
  * The syntax is super(...)

Q and A
Q: Don't you automatically get a zeroary constructor?
A: Only if you don't define your own.
Q: Does Java support multiple inheritance?
A: Multiple inheritance creates a host of problems: For example: When you subclass two classes with identically-named methods, which one do you get?
Q: What is multiple inheritance?
A: The idea that one class can subclass more than one class and inherit from both
  E.g., a car is both a wheeled vehicle and a gasoline-powered thing.
Q: Why do we typically have multiple inheritance?
A: Usually for polymorphism: We care more that the subclass has certain methods than that they are inherited

The interface: How to simulate multiple inheritance with fewer problems.

An interface is much like a class except:
* No fields.
* No constructors.
* No bodies to methods.
* Interfaces are "promises" to implement particular methods and used almost exclusively for polymorphism.

public interface Drawable
{
  public void drawMe(Window w, int x, int y);
}

public class DrawableFraction
  extends Fraction
  implements Drawable
{
  public void drawMe(Window w, int x, int y)
  {
    ...
  }
}

What's the difference between doing this and the same thing without the "implements Drawable"

Suppose we had a method, 
public void drawLotsOfCopies(Window w, Drawable d)
{
  for (int x = 0; x < 100; x++)
    for (int y = 0; y < 100; y++)
      d.drawme(w, x, y);
}
* Simplifies the compiler's check that d has a drawMe method
* Helps you think about the purposes of your classes

Abstract Classes: A Compromise Between interfaces and classes
Just like a class except
* Not all object methods need bodies.
* These you extend rather than implement.
* You can only extend one of these.

public abstract class {
}

/The Gil Question, Revisited/
* Some people just fit in better at Grinnell
* Nice people here
* A real liberal arts education: We get lots of different kinds of students in CS.  (Senior physics majors who aren't going to Berkeley, 3rd-year physics majors who decide to go to Berkeley, 2nd-year political science majors who get interviewed on TV)
* You'll get to meet lots of presidential candidates!
* Self governance rules!  (Even in this current model.)
* Faculty pretend to have power.
* Given your experience in this class, you're guaranteed to be more articulate than most students
* Our conclusion: Go to school in Europe or at least backpack there