CSC297.Java 2003F: Interfaces and Polymorphism

Admin:
* How go your Vector classes?
* Let's look at Bishop's next assignment

Overview:
* Design goal: Separate interface from implementation
* In Java: Interfaces (like classes)
* Polymorphism
* In Java: Abstract classes (more like classes)

Lessons from Vector Classes
* null != "null".  The first represents 'no such object'.  The second is a string.
* General design goal: If two procedures share a big chunk of code, parameterize that chunk of code and make it a new procedure.
  * Why?
  * Less code to type.
  * Probably easier to read.
  * Easier to fix errors.
* Why is it better to double the size of the array rather than adding 1 each time?
  * Consider if we started with a five element array and added ten elements.
  * Adding element 1: About 2 steps (test for size, set)
  * Adding element 2: About 2 steps (test for size, set)
  * Adding element 3: About 2 steps (test for size, set)
  * Adding element 4: About 2 steps (test for size, set)
  * Adding element 5: About 2 steps (test for size, set)
  * Yvonne's strategy
    * Adding element 6: About 7 steps (copy to new array, test for size, set)
    * Adding element 7: About 8 steps (copy to new array, test for size, set)
    * Adding element 8: About 9 steps (copy to new array, test for size, set)
    * Adding element 9: About 10 steps (copy to new array, test for size, set)
  * Sam's strategy
    * Adding element 6: About 7 steps (copy to new array, test for size, set)
    * Adding element 7: About 2 steps (copy to new array, test for size, set)
    * Adding element 8: About 2 steps (copy to new array, test for size, set)
    * Adding element 9: About 2 steps (copy to new array, test for size, set)

Trying to add n elements (n is a power of 2)
Sam's strategy, assuming we start with an array of size 1 and repeatedly double:
1 + 2 + 4 + 8 + 16 + 32 + ... + n/2 + n + 2*n
Yvonne's strategy, assuming we start with an array of size 1 and repeatedly add 1
1 + 2 + 3 + 4 + 5 + 6 + .... + n + 2*n

----------------------------------------

Object-Oriented Design, Revisited
* Primary design goal of languages: Make programmers more efficient (and more correct)
* It is bad to have to rewrite code to perform similar tasks.
  * At the procedural level, we can often create a common helper procedure.
* Sam's silly common mathematical task: square a number.
  * Right now:
	public int square(int val) { return val*val; }
	public float square(float val) { return val*val; }
	public double square(double val) { return val*val; }
  * Insanely repetitious
  * Consider similar procedures for objects
	public Float square(Float val) { return val.multiply(val); }
	public Double square(Double val) { return val.multiply(val); }
	public Double square(Integer val) { return val.multiply(val); }
  * Goal: Say "If x is something we can multiply, then we know how to square x."
* One mechanism: Provide a mechanism for stating capabilities

	public interface Multipliable {
	  /** Multiply this multipliable thing by another, similar, multipliable thing. */
	  Multipliable multiply(Multipliable other);
	}

* This says "Multipliable things provide a multiply method"
* If we create a class (say Rational) and want to say that it provides a multiply method, we write
	public class Rational
	  implements Multipliable
	{
	  ...
	}
* We can now write (somewhere else)
	public Multipliable square(Multipliable val)
	{
	   return val.multiply(val);
	}
* It will work for *all* multipliable kinds of numbers.
* The ability to execute one procedure on many different values of similar form is called "polymorphism"