COM 1204 Object-Oriented Design - Spring 2001 - Examples with Source Code

Professor Futrelle -- College of Computer Science, Northeastern U., Boston, MA

(Version of 5/16/2001)


Introduction and Overview

I hope the examples below show you that you only need to do a few things to get "early" versions of your programs working. As I've said in class, trying to "design it right" in the beginning can be a big mistake. Get little pieces of simple code working, test them, make slight additions, test them, and proceed in that way.

Latest Additions - the Base-Connection example (added 5/16/01): This code shows how you can do some modularization and how to use Vectors and Iterators to cycle through all the items in a collection, including safely and consistently removing an item during iteration, by using the remove() method of Iterator. The combined file is here.

More on iterators: The discussion of Iterators in Sun's tutorial is here. Another example is here. There's also a ListIterator that supports more methods.

At the end of this page, under "Designing and Implementing the Base Class" are some important ideas about getting your projects done that everyone should read, not just the people working on the Base class.

The "tiny" partially working example

This system, with source code was posted on April 17th. Here is a brief description of its components:

Here is the source code for this example.

The new (as of 4/29/01) example with a fairly complete Person and simple Phone

The point of this exercise is to show that a module, in this case a Person, can be tested when attached to a much simpler test module. Furthermore, the test can focus on a limited aspect of the functionality. In this case I have focused on the Person answering a ringing phone only, not initiating a call (not dialing). To test the Person, I've made a simple Phone that when stepped goes through a fixed series of steps of waiting, ringing, and responding to hangup.

For this test, I've called the two classes RingingPhone and RungPerson.

Note that various parts of answering a phone have been omitted for simplicity. For example, there should be a distinction between listening for a ring (listening to a hung up phone) and listening for a voice (listening to a picked up phone). Also there should be a pickup() function corresponding to the hangup() function.

Here is a brief description of its components:

The sources and the compiled code, which you can run in place in my directory, are in ~futrelle/personphone/. Just execute java RungPerson.The three source files are also on the web: PUtil.java and RungPerson.java and RingingPhone.java. In addition, the Javadoc pages can be accessed here.

This is the output of the 20 step run by PersonPhone. It's not quite right, since the phone should start emitting an empty message once it's hung up. But at that point the phone stops listening, it "can't" listen, so it doesn't report that it heard anything even though the phone has that string available.

A TestPhone returns -><- to a listen().
A TestPhone returns -><- to a listen().
A TestPhone returns -><- to a listen().
A TestPhone returns ->RING!<- to a listen().
RungPerson heard a RING!
A TestPhone returns ->just sayin' whatever ..<- to a listen().
RungPerson heard ->just sayin' whatever ..
A TestPhone returns ->just sayin' whatever ..<- to a listen().
RungPerson heard ->just sayin' whatever ..
A TestPhone returns ->just sayin' whatever ..<- to a listen().
RungPerson heard ->just sayin' whatever ..
A TestPhone returns ->just sayin' whatever ..<- to a listen().
RungPerson heard ->just sayin' whatever ..
A TestPhone returns ->just sayin' whatever ..<- to a listen().
RungPerson heard ->just sayin' whatever ..
RUNGPERSON HANGS UP
A RingingPhone WAS HUNG UP
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().
A TestPhone returns ->just sayin' whatever ..<- to a listen().

Notes on designing and implementing the Base class

The Base is complex, so some people are having a difficult time with it. But here's a fundamental point that everyone should understand, not just the students trying to implement the Base: When you're facing a difficult software design and implementation problem, start by designing something simpler. This does not mean that your implementation is wrong or deficient, it just means that you're proceeding in a sensible and stepwise manner. You must ignore much of what you were asked to do, design a much simpler system and proceed from there.

Here's one suggestion, a serious suggestion, for a simpler Base class and associated system that you could work on: Restrict your system to only two phones. The ether would have only two forward and two reverse channels, assigned to the phones in advance. There would be no number to dial, dial() would need no argument at all, since there's only one other phone besides the one dialing. (Imagine it more like a point-to-point intercom system.) If you got an entire system working with this design it would be a really fine accomplishment. Depending on how much everyone is able to do, such a simplified system may even end up getting full credit. Time will tell.


Go to COM1204 home page

Return to Prof. Futrelle's home page