Class 48: Design Discussion

Held Friday, April 30

Summary

• Exam 3 distributed. Due Friday, May 7, 1999.

Contents

Handouts

• Exam 3

Notes

• Once we've resolved issues today, you should plan on having mostly-working classes ready by Tuesday. The sooner you can get ``stub'' classes working, the sooner other folks can start trying to integrate.
• I'll reserve time at the start of classes next week to discuss the exam. I'd prefer to hear questions on Monday.

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:

• Naming of methods. Method names should always begin with a lowercase letter. Some of you consistently (or, worse yet, inconsistently) violate this.
• Separation of interface from implementation. Many of you have given many too many details about implementation (``It's going to be an array and the key is an index into that array''). This will make it difficult to change the implementation.
  • It's fine if you have such plans in your head; they just need to be documented slightly differently.
• Failure to consider problems. Almost none of your classes throw exceptions. (I'll admit that I didn't document mine well, but that's better than not having them at all.)
• Instructions. In many cases, it's not clear how one starts a program using your class. This is particularly important for the GUIs, the reporter, the analyzer, and the database.
  • We'll use DatabaseServer to start the database. That class has some basic documentation.
• Stubs. Many of your classes aren't compilable in the current form. In part, this is because the stubs for the methods that return values don't actually return values. You need to work on this ASAP.

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:

• Art
  • Title (to be distinguished from Name for the reasons below)
  • Medium
  • Genre
  • Size (probably three ints for width, height, and depth)
• Person
  • Local contact information (hotel, hotel room, phone)
• Artist

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).

• For art: Title (Artist)
• For artists: LastName, FirstName (Suffix)
• For bidders:

Miscellaneous

• All the set/get methods are missing from Art.

Database

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.

• Lookup vs lookupByKey
• add vs addNew
• replace vs update
• ListAll vs. list
• ListByField vs. lookupByField

Other are more global design.

• DatabaseClient does not include presentInData. Why not? Because in most cases, knowing that something similar is present doesn't mean that we don't want to add things (which was why we set up this function). Rather, it would help to get a list back of similar things, and decide if we're equal to any of them.
• DatabaseClient does not include reset. Should it?
• DatabaseClient does not include clone. Should it? I'd argue not, since we can clone a database by dumping it to a file and then loading from that file.
• DatabaseClient does not include readFile. Should it?
• Database does not include newId. Should it? What are our alternatives.

GUIs

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?

Uniformity

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.

Passwords

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.

Genericity

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();
    ...
    else
      super.getField(fieldName);

Networking

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.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in details on Thursday, April 29, 1999.
• Filled in a few more details on Friday, April 30, 1999.