See class16.html for midterm review: there is coverage of writing static methods, still good to review. Also arrays and interfaces.
Since the midterm, we have studied Interfaces, ArrayLists, boxing and unboxing, the Comparable interface, Object class and equals, sorting and searching, and finally inheritance
Interfaces: covered in hw3 (before midterm), hw4 (Vehicle interface, as opposed to later Vehicle inheritance hierarchy)
ArrayLists: also more on arrays
ArrayList<String>: covered well in hw4
ArrayList<Integer>, ArrayList<Double>: not covered enough in hw or projects: needs boxing and unboxing, but might be on final. Try #6 and #12, pg. 674 (solved)
ArrayList<ObjectClass>: covered in p3 ArrayList<ITSystem>
Comparable interface: implemented for us in String, Integer, Double. No hw on doing our own coding, so that won’t be on final.
Equals method of Object: figured in p3, and of course String equals. Tricky to implement for our own classes. Understand the Point and ITSystem examples.
Sorting: covered in p4 for array/ArrayList of String. Generalize to array/ArrayList of Integer, Double for the final.
Searching: used in p3 using indexOf. Should know that binarySearch is faster, but requires sorted collection.
Inheritance: most advanced topic, covered in hw5. Make sure you can do #11-12, pg 619 (problems 6 and 7 of hw5). Note that #13 and 14 of pg. 623 give another solved exercise on this.
Interfaces: at least as important as inheritance. Revisit hw3 to make sure the inheritance coverage hasn’t interfered with your understanding of interfaces.
When to use interfaces vs. Inheritance: a good question, discussed a little, but don’t worry about it for the final—just know how to use each as directed.
When to use arrays vs. ArrayLists: this you should be able to do on the final. ArrayLists are stretchy, so great for holding data that is input to the program. They are also easier to print out because they implement toString. Arrays have the nice initializer syntax. And of course it’s nice to be able to use a[i] notation.
An API is a list of method headers for public methods of the class, of form
<returntype> <methodname> (<paramtype> <paramname>, …)
Both object classes and non-object classes have APIs. For object classes, we also list constructors:
<classname>(<paramname> <paramtype>, …)
To find an API from given code, simply find all the methods, drop any private methods, and copy out the very first line, dropping any “public” or “static” keywords.
We noted that our classes either have all static methods, or all non-static (object or instance) methods. It is possible for a class to have both, but that’s an advanced topic.
Interfaces are just APIs (for object classes only) turned into Java by starting with “public interface interfacename { then listing the API with semicolons at the end of each line, then finally adding }. In the book, “public” keywords are used too, but they are not necessary.
We say "X IS-A G" (G
for the more general type) to mean that the type G is substitutable for the
type X. Wherever we need a ref of type X, we could instead use a ref of type G,
the more general type.
Note that an API of a class gives you enough information
to write client code. An interface needs a class implementing it to be complete
enough to write client code, since you can’t create an object of pure interface
type.
Don’t worry about class diagrams for the final. We just
used them to illustrate inheritance.
I’ll provide a practice final by Thursday.