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