Java has packages, which are collections of classes and interfaces. There are also mechanisms for information hiding within a package, which is good. But we normally think of a module as including functions and variables as well. In Java we collect those things together by putting them in a class. What would normally be free-standing functions and variables in a module become static elements of a class. The Math class in Java is a classic example. It has static variables Math.PI and Math.E and static methods like Math.sin, Math.cos, and Math.abs.
Then I briefly revisited the idea of static versus dynamic properties of programs. I have been keeping a 2-column list of various properties we have discussed:
static dynamic
compile-time run-time
compilers interpreters
static type checking dynamic type checking
lexical scope dynamic scope
flow of control
I said that I wanted to briefly mention polymorphism, which is a dynamic
property. We considered a class defined as follows:
public class Foo() {
public void method1();
System.out.println("howdy");
}
public void method2();
method1();
}
}
And I asked people to consider client code like this:
Foo x; ... x.method2(); // always prints "howdy"?On the surface, it appears that this will always print "howdy", but that's not necessarily the case. There could be a subclass of Foo that overrides either method2 or method1, which could change the behavior. I asked people whether we can figure this out at compile-time. Couldn't we look at the code and figure out what kind of object the variable x will refer to?
The answer is no. For example, the program might prompt the user and ask the user to pick which kind of object x should refer to. It could be even worse. The line of code above could be inside a loop that sets x to refer to different kinds of objects on different iterations of the loop. So the exact same line of code can end up calling many different methods.
This is an important property of Java that we call polymorphism. It has many other names including dynamic binding, late binding, runtime binding and dynamic dispatch. So this single line of code can lead to several different methods being executed. This is similar to the dynamic scope example we had where a single reference to a variable x could end up referring to several different variables.
The idea behind calling this dynamic dispatch is that at runtime you need some kind of dispatching code that figures out which method to call depending upon the type of object that is in use. So in the case of dynamic scope, the general feeling seemed to be that it's confusing and not worth it. Why is it worth it to do dynamic binding? Some people think it isn't. In C++ you'd have to declare a method as "virtual" to get this behavior. The designers of C# decided that the default behavior of methods in C# would be static unless you attach the same "virtual" keyword to a method. So in those languages you have to go out of your way to get dynamic binding.
So we can add "polymorphism, dynamic binding" to our list of dynamic properties of a program. For the designers of Java the feeling was that dynamic binding should be the default to keep the language simple and because inheritance is so powerful.
We spent the rest of the lecture discussing the next programming assignment and the Monday midterm.