CSU213 Lecture Notes Spring 2008

Lecture 1: January 7, 2008

This class is not about Java. It's about how to design programs. We will use Java as the programming language to develop programs.
All you need to know prior to this class you have already learned in kindergarden (i.e. in Fundamentals of Computing 1).
In this lecture we focus on recalling how to design programs with accumulators in the Beginner HtDP Language - and in the process recall the design recipe for data definitions and for functions.

One can only understand computing if one understands the connection between the information provided by the user and the way the information is represented as data that the program manipulates.
We will look at what we already know about data definitions and learn that the same information can be represented as data in a different language.
However, the most important lesson is that the data no matter how represented corresponds to the same information, and that the structure of the data representation is identical in two different programming languages.

Unions of data combine several related classes of data under the same name. Unions of data combined with a self-referential containment represent quite complex structures of data, such as ancestor trees and lists.
While in HtDP this common name did not have any meaning within the language, class-based programming languages not only provide for a language-based definition of commonality among several classes of data, but later leverages this commonality in program design.
The most important lesson here is that a piece of data can be an instance of some class of data, and at the same time be known to represent data of a given type (super-type). So, for example, an instance of a Book is also an object of the type LibraryItem.

Part 1: Self referential data.

Unions of data combined with a self-referential containment represent quite complex structures of data, such as ancestor trees and river systems.
We look at how the data definitions we have seen in HtDP translate in a systematic way to class-based data definitions.
The most important lesson here is that following the DESIGN RECIPE for data definitions we learned in HtDP helps us in identifying the classes of data we need to define and the relationships between the classes and interfaces.

Part 2: Designing Methods.

Designing methods for a class-based language is very similar to designing function in functional languages.
The main difference is that in a class-based language a method is invoked by an object of the class in which the method is defined. This object than becomes an implicit argument to the method.
The most important thing to remember is that the program designer need to think very carefully which class should be responsible for defining a method that may involve instances of more than one class.

Designing methods for a unions in a class-based language leverages the fact that the interface that represents the union has a meaning in the language.
In a class-based language when an instance of a class invokes a method, the method definition lookup is dispatched first to the class to which the instance belongs.
The most important thing to remember is that the method dispatch eliminates the need for the conditional we used in HtDP to distinguish between the variants of a union. However, we are now responsible for defining the method with the same signature in all classes that implement the common interface.

Designing methods for a unions in a class-based language leverages the fact that the interface that represents the union has a meaning in the language.
In a class-based language when an instance of a class invokes a method, the method definition lookup is dispatched first to the class to which the instance belongs.
The most important thing to remember is that the method dispatch eliminates the need for the conditional we used in HtDP to distinguish between the variants of a union. However, we are now responsible for defining the method with the same signature in all classes that implement the common interface.

Designing methods for self-referential unions typically leads to a self-referential method invocation by a field in the class that is itself an instance of the class.
Including the method declaration (method signature) in the common interface defines a contract between the interface and all of the implementing classes; requiring that each of them implements the specified method.
The most important thing to remember is that as in HtDP, learning to read the purpose statement in the context of this self-referential field, typically provides a deeper understanding of the program behavior and helps greatly in the method design.

The rule of one task, one function we learned in HtDP is just as relevant in the context of class-based program design.
In complex class hierarchies, following the arrows in the class diagram often serves as a guide where the method that solves the next task should be defined.
The most important thing to remember is the rule delegate each task to the class that should be responsible for providing the answer.

In the previous course we used the DESIGN RECIPE FOR ABSTRACTIONS to eliminate repetition in the code. This is not just an aesthetic issue - it also help in following the single point of control principle.
We start by identifying the situations where the current data definitions (with interfaces representing unions of data) do not give us enough power to design the programs we need to design. We then introduce several solutions to our problem.
The most important thing to remember is that while an abstract class provides a common base for several classes that extend it (its subclasses or derived classes) we cannot construct an instance of an abstract class.

We can now eliminate repetition from the method definitions as well --- continuing with the theme of the single point of control principle.
We look for methods that have a common implementation in several classes. At times, we can lift the entire implementation into the abstract class --- defining concrete methods in an abstract class. In other cases the implementations in different classes may be completely distinct, and there is no abstraction possible. The third situation occurs when several classes share the implementation of a method, but one class may differ. In that case we may implement a concrete method in the abstract class and let the one class that needs a different implementation override this method.
The most important thing to remember is that abstract class is a perfectly good place for defining methods. However, every class that extends this super class must provide tests for each such concrete method.