Session 3

The Anatomy of a Java Program

CS 2530
Intermediate Computing

Last week, we played with a simple memo pad application and opened up its code. Today, we examine this code in greater detail and try to understand the anatomy of a Java program. We will use it as a vehicle for understaning the anatomy of an object-oriented program.

Static Versus Dynamic

a homegrown class diagram of the memo pad app

A common question students had after reading the memo pad program before our last session was,

What happens when the program runs?

This is an important question! [... Your experience is with imperative programs in the small, often in a single file. One function calls another, calls another. In our Java program, which parts call which other parts, and when? ...]

Last time I drew a simple class diagram of the memo pad program, similar to the one we see here. This picture shows us the structure of the code in its static form, as we read it on paper. But it doesn't answer your question about what happens when the program runs. That is a question about the program's dynamic behavior.

[... the distinction between a program's static structure and a program's dynamic structure is one of computer science's big ideas. Algorithms, languages, compiler. ...]

Let's answer your question by looking at a typical run of the program and tracing what we see back to the code. This will give us a sense of "the flow of the application", allow us to see how multiple objects collaborate to solve the problem, and make us pay attention to the details of Java at a more concrete level. In particular, we will have to study a piece of code we skimmed over last time: the constructor.

The Big Bang

Before we can interact with a memo database, we have to run the program. MemoPadApp is the starting point:

    MemoPad p = new MemoPad();;

We will return to this class again later....

What happens when we start the program?

After the big bang, another static structure exists: [an object diagram]. Notice that this network of objects does not include a MemoDatabase. Why?

What happens if we create a second MemoPad while the first is still running?

Now we are ready to talk about what happens when we use the program.

A Sample Interaction

Step 1: Add a memo to the database.

... user interacts with the text field and insert button. Let's save most of the details of this for a couple of weeks.

In response to pressing the insert button, something sends an insert message to the memo pad. In response, the memo pad executes its insert method:

    public void insert()
       MemoAssociation memo = fieldPanel.currentKeyValuePair();
       if ( !database.insert( memo ) )
          messagePanel.setMessage( memo.key() + " already used." );
          messagePanel.setMessage( memo.key() + " : " + memo.value() );

The memo pad asks the field panel for the current key/value pair and asks the database to add the pair. It responds to the user accordingly.

The memo pad's job is to act as a go-between, coordinating other objects that do specific tasks and interacting with the user. That's a pretty good description of every object in an OO program. Some objects 'do' more than 'coordinate'...

... Java features:

The memo pad sends the same message, insert, to the database. ... common. ... different behavior, so this is not recursion as you've seen it in the past. (More later this semester.)

In response to an insert button, the database must respond true or false. Let's follow the message, where we will find a simpler class that we can understand all of now. It will help us learn more Java in a simpler setting.

... open up DefaultMemoDatabase. Look the boolean response from the insert method. Consider other similarities to previous code.

Wrap Up

Eugene Wallingford ..... ..... August 28, 2012