2 Lecture 2: Data Definitions: Unions

Design of classes that represent a disjoint union of sets of data. Extending unions to represent self-referential data.

Related files:
  Unions.java     AncestorsData.java  

Outline

• Representing unions of data sets

• Making examples of unions of data

• Self-referential unions

• Information and data - understanding the connection

Unions: Traveling on the T in Boston

So, in DrRacket the data definition would be:

;; IStation is one of

;; -- T Stop

;; -- Commuter Station

;; T Stop is (make-tstop String String Number)

(define-struct tstop (name line price))

;; Commuter Station is (make-commstation String String Boolean)

(define-struct commstation (name line express))

(define harvard (make-tstop "Harvard" "red" 1.25))

(define kenmore (make-tstop "Kenmore" "green" 1.25))

(define riverside (make-tstop "Riverside" "green" 2.50))

(define backbay (make-commstation "Back Bay" "Framingham" true))

(define wnewton (make-commstation "West Newton" "Framingham" false))

(define wellhills (make-commstation "Wellesley Hills" "Worcester" false))

This can information and data organization can also be represented by the following class diagram:

This diagram demonstrates two new concepts: first, it gives a common name to the data type that represents both kinds of station by defining an interface IStation. Second, it shows two classes that implement this interface, as indicated by the hollow-triangle arrow on the line connecting the classes to the interface. Colloquially, we say that "TStop is a IStation, and so is CommStation." This is a key distinction: Contrast this with the v-shaped arrowheads in the diagram in Lecture 1, which were used to indicate that Book "has-a" Author field. Here, we are indicating that TStop "is-a" IStation. "Has-a" and "is-a" relationships are important organizing concepts for our data definitions, so our diagrams help us track this information. Interfaces are how we will inform Java about our union data types that (until now) had been described only in comments, and declaring that a class implements an interface is how we inform Java which classes are part of our union.

The data definitions then become:

// to represent a train station interface IStation {

}

// to represent a subway station class TStop implements IStation {

String name;

String line;

double price;

TStop(String name, String line, double price) {

this.name = name;

this.line = line;

this.price = price;

}

}

// to represent a stop on a commuter line class CommStation implements IStation {

String name;

String line;

boolean express;

CommStation(String name, String line, boolean express) {

this.name = name;

this.line = line;

this.express = express;

}

}

The syntax for defining interfaces is to use the interface keyword, followed by the name of the interface (which by convention will always start with an uppercase "I"), followed by braces. (You may have guessed from the fact that interfaces have a brace-delimited block that perhaps something can be written there, like the body of class definitions. We will see in Lecture 4 how to use this space.)

The syntax for declaring that a class implements an interface is to add the keyword implements just after the class name, followed by the name of the interface.

Defining Examples of Data

As before, we define examples of data in a corresponding class ExamplesIStation:

class ExamplesIStation{

ExamplesIStation() {}

/* Harvard station on the Red line costs $1.25 to enter Kenmore station on the Green line costs $1.25 to enter Riverside station on the Green line costs $2.50 to enter   Back Bay station on the Framingham line is an express stop West Newton stop on the Framingham line is not an express stop Wellesely Hills on the Worcester line is not an express stop */

IStation harvard = new TStop("Harvard", "red", 1.25);

IStation kenmore = new TStop("Kenmore", "green", 1.25);

IStation riverside = new TStop("Riverside", "green", 2.50);

IStation backbay = new CommStation("Back Bay", "Framingham", true);

IStation wnewton = new CommStation("West Newton", "Framingham", false);

IStation wellhills = new CommStation("Wellesley Hills", "Worcester", false);

}

How do we use these examples?

Enter the Tester

Lab 1 introduces you the Tester library, which provides facilities for testing your code, much like you had in Fundies 1. However, unlike Fundies 1, the test forms are not part of the language; in Java, we’ve had to write a tester library for you, and its functionality will be explained over the next few days.

If you follow the instructions in Lab 1, and then run the program above, the tester will automatically create an instance of our ExamplesIStation class for us, and display the data as follows:

Exercise

What would need to be done to represents all stops on all bus lines, including the express bus lines?

Self-referential unions: Ancestor trees

Suppose we want to represent an ancestry tree for a person, naming the ancestors as far as we can remember, and using ‘unknown’ for those nobody can remember or trace.

Here is the data definition in DrRacket:

;; An Ancestor tree (AT) is on of

;; -- 'unknown

;; -- Person

;; A Person is (make-person String AT AT)

(define-struct person (name mom dad))

and here are a few examples:

(define mary (make-person "Mary" 'unknown 'unknown))

(define robert (make-person "Robert" 'unknown 'unknown))

(define john (make-person "John" 'unknown 'unknown))

(define jane (make-person "Jane" mary robert))

(define dan (make-person "Dan" jane john))

Two important skills you need to practice early are:

• design a representation of the given information as data

• interpret the given data as the information it represents

So, here, to understand what the data shown above represents, we may want to draw the ancestor tree, so we can tell easily how the different people are related. The given data represents the following ancestor tree:

(For brevity, we’re using the ? for the ‘unknown’ names.) The class diagram that represents this data definition looks like this:

We replaced AT with IAT since in Java the union type will be represented as an interface, and our naming convention tells us to start the names of interface types with the uppercase letter I.

Note the two kinds of arrows here: Person and Unknown both implement IAT, while Person also has two IAT fields.

The code below shows how this class diagram and our examples can be translated into a represetation as Java classes and interfaces (slightly misnamed as a Java class hierarchy):

// to represent an ancestor tree interface IAT{ }

// to represent an unknown member of an ancestor tree class Unknown implements IAT{

Unknown() {}

}

// to represent a person with the person's ancestor tree class Person implements IAT{

String name;

IAT mom;

IAT dad;

Person(String name, IAT mom, IAT dad){

this.name = name;

this.mom = mom;this.dad = dad;

}

}

As you may remember from last semester, we can define interesting behavior for unions, by defining functions that distinguish between the cases of the union and return different results in each case. In Lecture 4, we will see how this works in Java, which will involve enhancing the definitions of Unknown, Person, and IAT.

Examples of Ancestor Trees

As before, we define examples of the data in the class named ExamplesAncestors:

At the time the program is checked for corectness by the compiler, the compiler knows that mary is of the type IAT (also known as its compile-time type; when the program runs, it will also know that after the data definition has been made, the run-time type of mary is Person.

We can see this when the Tester library displays our data:

When designing a program, we must make sure that the compile-time types af all data items (variables and arguments) correspond to what the compiler can expect. (More about this later.)