Fundamentals of Computer Science II (CSC-152 99S)

Class 48: Design Discussion

Back to Lab: Traversing and Iterating Trees. On to Introduction to Graphs.

Held Friday, April 30





These are some observations as I looked at related assumptions and such in the code files. They will serve as the basis of our discussion on Friday, April 30, 1999. However, as a group we may reach different decisions or identify other important issues.

General Issues

As I may have mentioned already, there are a number of general issues that we need to consider. These include:

Core Data Classes

The GUI folks will be responsible for finishing their corresponding core data classes. This helps ensure that everything meshes where it is most important that things mesh.

More Fields

Looking at the definitions of the core data classes, it's clear that we had a number of different ideas about what belonged in those classes. I've clearly left some things out. Here are some fields that will be added, along with corresopnding methods:

A Note on Naming

We also need to make it clearer that the name is somewhat special: it is something that one can look at quickly in order to distinguish between similar entries (e.g., two pieces of art with the same name).



We seem to have different ideas about keys. Both strings and integers are used as keys. I'd prefer to use strings, since it gives the implementers some more freedom. (Since they get to choose the strings, they can use strings that correspond to integers. They might also encode some other information in the string.) There is also some uniformity if we use strings. That way, key, id, and name are all strings.

There is some confusion about who assigns or generates identifiers. For now, it is probably best if the database does this.

It would be nice if Database and DatabaseClient had the same methods. (It might also be worth looking at GUIEncoder and friends, although I think it will be more work to change them.)

In fact, we are probably better off creating a Database interface, and having DatabaseClient (the "glue" team) and RealDatabase (the "database" team) implement that. The database team will be responsible for the interface.

Some things are just an issue of naming.

Other are more global design.


Everyone should try to bring up the GUIs so that we can discuss them. In many cases, it's not clear to me what happens when people press the various buttons. For example, if I get a list of art by entering an artist's name, what does the list look like? Where do I go from there?


As much as possible, the three administrator GUIs should look and behave in the same way. This makes it easier for the administrator to actually use them.


Although we decided that we needed password access to the database, none of the GUIs seem to have included a facility for asking for the password.


It would be nice if things were as generic as possible. In particular, it should be relatively easy to add a new kind of object to the database or a new field to one of the objects already stored in the database. Think to yourself ``how can I make my work less when someone wants to update what our project does?''. What helps support this?

The ObjectType class gives us a quick way of naming kinds of objects. It might be helpful if each class had a getType method which returned its corresponding object type.

To make it easier for the database to extract information from entries, we might want to support a getField method, of the following form:

   * Extract the contents of an actual or implied field.
   * Throws an exception if no such field exists of if there
   * is no reasonable way to represent that field as a string.
  public String getField(String fieldName) 
    throws Exception
  } // getField(String)

For example, here is part of the getField method from the Person class.

    if (fieldName.equals("firstName")) 
      return firstName;
    else if (fieldName.equals("lastName"))
      return lastName;
    else if (fieldName.equals("zip"))
      return address.getZip();


Since we've now chosen a design that hides the network infrastructure from the GUIs and the database, and almost none of you are responsible for anything but GUIs and databases, we won't discuss networking issues.


Back to Lab: Traversing and Iterating Trees. On to Introduction to Graphs.

Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

This page may be found at

Source text last modified Fri Apr 30 10:53:15 1999.

This page generated on Fri Apr 30 10:59:41 1999 by SiteWeaver. Validate this page's HTML.

Contact our webmaster at