CSC297.Java 2003F, Class 13: Polymorphism Continued Admin: * Bishop hasn't assigned anything this week. * What homework should I assign you? * Write a procedure, center(screen,Object,width) that prints the object centered in width columns. * Think about how we might implement Scheme-like lists in Java. * Hint one: Create a Pair class. * Hint two: Use a vector backwards. Overview: * Interfaces, revisited * Numerical example, continued * Other benefits of interfaces * Abstract classes Intefaces contain only names of object methods * No fields * No constructors * No static methods * No bodies to the object methods Classes "implement" interfaces * Really a way of saying "this class *is* one of these things" * The methods from the interface must be redefined and have a body. Observations: * Some simplification, but we still have to worry about how to deal with "non-matching" types * We often decide that throwing exceptions is okay in such cases. * The documentation should probably indicate that the type restriction is more severe * We've been using this idea for awhile: Java assumes that classes provide a toString method and calls it whenever we add an object to a string. Another use for interfaces: * Separate "what my class should do" from "how my class does it" * As clients of something like a list, we care not about how they are implemented, but what they can do. * As implementers, we care about how they are implemented. * When we design our own types, we will usually use interfaces. * E.g., lists public interface SchemeList { /** Get the first element of the list. */ public Object car(); /** Get all but the first element of the list. */ public Object cdr(); // Can't be in an interface. Whoops. /** Is the list empty? */ public boolean nullP(); // Add eomthing to the front. public SchemeList cons(Object newFront); } // interface SchemeList public class StudentRecords { SchemeList students; ... public Student enroll(Student s) { students = students.cons(s); } public Student lookup(Student s) { ... } }