CS201 - Spring 2014 - Class 10

  • Quick review of where we've come
       - all new syntax with Java
       - defining classes
       - static
       - final
       - object oriented programming
       - nuances of a new language
          - I/O
          - new classes (Random, ...)

  • Major hurdles left
       - Today, finish up interfaces
       - Only one more major conceptual thing to talk about next week with Java (and then, data structures!)

  • look at the BadJavaInterfaces class in the InterfaceBasics code
       - Let's pretend that Java doesn't have static type checking
          - That's what python and netlogo do
       - What types of objects could you call the mystery1 function with if we wanted to be sure that all the methods exist for that object?
       - Put another way, what methods do we want to make sure the object passed to the mystery1 function have?
          - Without the type (i.e. if we just try and say Object), it is very hard to tell!
          - We have to follow through all the calls that involve that object (including calls of calls, etc.)
       - Java could figure this out, but how do we communicate that information concisely to the user?
          - It's hard!
       - What happens if we want to call another method on object o?
          - That could change everything!
          - and maybe it's not legal, i.e. we don't want to be able to

  • static typing
       - Java is a statically typed language
       - Every variable and every parameter has a type
       - The *type* dictates what methods can be called on that variable/parameter
       - static typing requires labeling everything with its type
       - the benefit is then that many bugs/errors can be found without having to run the code!
          - and we also get some nice other features, like autocomplete in Eclipse (type a variable name followed by a .)
       
  • Interfaces
       - In most of the code we've looked at so far, the class definition dictates the methods that we can call on an object
       - A class is both:
          - the specifications of the methods that you can call on this object (i.e. defining a type)
          - AND the definition of those methods
       - We've seen that we can say that two classes share a specification (i.e. a set of methods) through inheritance
          - if class B extends class A, then B has all of the methods of A and can therefore be used anywhere an A can be used
       - Interfaces are a more general framework for specifying the methods that you can call on an object
          - An interface defines the methods a class MUST define/have
          - An interface is NOT a class
          - An interface DOES define a new type

  • Defining an interface
       - to declare a new interface, you define the method headers, but not the bodies of the methods:

          public interface A{
             public void printYeah();
             public int returnANumber();
             public String returnTheString(String s);
          }
       
  • Using an interface
       - A class can then choose to "implement" that interface, by:
          1) adding "implements <interface>" in the class definition
          2) implementing all of those methods in its body

       - For example, look at the BClass class in InterfaceBasics code
          - We have all three of the methods required for the interface implemented
          - We also have other methods

       - An interface defines a type
          - Any class that implements the interface can be used where a variable/parameter of the interface type is required
          - Just like with inheritance, if we've declare a variable/parameter as that type, we can *only* use methods defined in the interface
       - Look at the demo2 method
          - We can declare an object of type BClass
          - Why can we assign temp to the variable a?
             - What methods can we call on variable a?
                - only the methods defined by the interface
             - since BClass implements the interface, then we know those methods exist, so it's fine to store a BClass object in an AInterface object.
          - Why can't I include the last line (the one commented out) in demo2?
             - For a variable of type AInterface, the only thing we can guarantee is that it has the methods defined in the interface
             - Just like with inheritance, the variable dictates the methods that can be called

  • Look at the GoodJavaInterfaces class in InterfaceBasics code
       - What types of objects could you call the mystery1 function with if we wanted to be sure that all the methods exist for that object?
       - Put another way, what methods do we want to make sure the object passed to the mystery1 function have?
       - It's very clear now!!!
          - static typing can be a pain, but can also be a very powerful tool for:
             - finding errors early
             - communicating information between programmers
             - speeding up the program since we can avoid a lot of checks

  • Back to our sorting example
       - If you look at the documentation for the Arrays.sort method (http://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#sort(java.lang.Object[])):
          "All elements in the array must implement the Comparable interface"

          - realistically, this method really should be:

             public static void sort(Comparable[] a)

             however, for legacy reasons (Java's pretty old), it takes an Object[] array and then almost immediately casts it to a Comparable array         
       - Looking at the Comparable interface (http://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html), we see we only need to implement one method, compareTo
       - Look at the Card class (maybe the last time) in InterfaceBasics code
          - I've implemented the compareTo method
             - it returns an int and takes another Object as a parameter (similar to equals)
             - how does this version of compareTo sort?
                - only sorts based on the number
                - if we wanted to also take the suit into account, we'd have to work a bit harder at it
       - If we now go back to the sortCards method in the SortingArrays class in the InterfaceBasics code and run it with the revised code, we'll see it now sorts the cards!
          
          Before:   [Queen of spades, 10 of diamonds, 8 of diamonds, 4 of hearts, King of clubs, 2 of diamonds, Jack of diamonds, 9 of diamonds, King of hearts, 7 of clubs]
          After:   [2 of diamonds, 4 of hearts, 7 of clubs, 8 of diamonds, 9 of diamonds, 10 of diamonds, Jack of diamonds, Queen of spades, King of clubs, King of hearts]

  • merge sort