Project Proposals, Stage Two

This is my summary of what the various Teams gave me on Monday, October 11, 1999.

• The Basics
• Classes
• Teams
  • Team Aardvark
  • Team Bison
  • Team Camel
  • Team Chipmunk
  • Team Emu
  • Team Flamingo
  • The Team Who Would Be King

The Basics

I don't know how to make this clearer: You will not get the project done if you don't keep up on the parts of the project! Your goal for today was reasonable:

• Read my notes on your first round and reflect on the discussion.
• Write interfaces for each of your classes.
  • I expected that these would compile.
• Document clearly what each method does and what parameters it takes.

Classes

• Address.java
• Condition.java
• Folder.java
• MessageInfoList.java
• Name.java
• Network.java
• Options.java
• PersonalProfile.java
• Photo.java
• Rule.java
• SortFilter.java
• StreetAddress.java

Teams

Team Aardvark

Nothing turned in. Goal was start of implementation of GUIs.

Team Bison

Grade: Good

Classes:

• Network.java

I'm a little bit confused. It appears that this one class serves the purpose of the network, the mailbox, and the maildrop. I'd prefer to see separate classes (and, preferably, separate interfaces).

I'd also like to see something about constructors.

Given that you've tied everything together, you need to more carefully document what needs to be done in what order. For example, what happens if I try to list folders without connecting to the server or logging in?

It doesn't compile. (I know, that wasn't required, but it woulod have been nice.)

You haven't created the accompanying exception classes. You also haven't told me much about when exceptions might be thrown.

Some minor notes:

• I'm not sure why getFolderContents returns an array of strings rather than an array of message headers (or even some form of MessageList).
• Similarly, I'm not sure why getMessage returns a string rather than a Message.
• There were a few extra semicolons (e.g., after the definition of bye).
• You've documetned exceptions incorrectly. Use

  /**
   * Yadda yadda yadda.
   *
   * @exception ConnectionException
   *   when ...
   */
  

Team Camel

Classes:

• MessageInfoList.java
• Rule.java
• SortFilter.java
• Folder.java
• Condition.java

Grade: Fair

Short Notes:

• You need to talk more with the network, interface, and preferences groups.

Condition

• I agree with the suggestion that the operators be made into a class. You should also think about how Conditions relate to Comparators.
  • You should think about the multiple uses of your conditions. Sometimes they are used for selection. Sometimes they are used for ordering.
• I also agree that it would be nice to accept wildcards in the patterns. However, I also think those will be hard to implement, so you are not required to do so. (There are some existing classes on the Web that you might use.)
• Your fields need Javadoc comments.
• Your constructor comments need more details. What kind of condition do you get from the null constructor?
• In many cases, the code would have only taken you five more minutes.
• You haven't documented what the setXXX methods return.
• Are you sure that rules need the setXXX and getXXX methods?
• Doesn't isRuleTrue need some parameters? For example, don't you want a mailmessage to consider?

Folder

• I'm not sure what purpose this class serves. It seems to be something that the mailbox cares about. Your responsibility is really just organizing and filtering message lists.
• Note that your group and the network group have approached folders in very different ways.

MessageInfoList

• A goal of this class should be to hide the underlying array, not to make it explicit.
• Think about who would use this class and how.
• I have no idea what makeNewList does.

Rule

• This seems to be ``things to do in order to move stuff to a folder''. I'm not sure about the name.
• Do you really need the set and get methods? (You might, but you should think about it.) Please chat with the specifications class about it.
• Do your really need the class. Couldn't your Condition class have a filterIntoFolder method?

SortFilter

• You haven't indicated how a series of rules can be used in sorting.
• Again, it's not clear that you need all the get and set methods.

Team Chipmunk

Classes:

• Photo.java

Grade: Very good

Short Notes: Most of what I expected in the design. I would have preferred a separate interface, rather than just a class. Otherwise, provides sufficiently many details.

I do wonder how setPhoto relates to the other stuff. One possibility is to add a separate PhotoDatabase interface (and, eventually, a class). That could then include the setPhoto method.

Team Emu

Classes:

• Address.java
• Name.java
• Options.java
• PersonalProfile.java
• StreetAddress.java

Grade: Poor

Summary: This group seems to have missed the point. While they created a number of classes, none of the classes is sufficiently well documented for it to be useful.

Discussion: As I mentioned in the notes on the first round, it's difficult, if not impossible, to predict all the options that the various classes would need. Hence, I suggested having generic methods that get and set particular kinds of options (boolean, string, general object). The group seems to have ignored that advice without giving an explanation as to why.

The classes they've created are not very useful in their current form.

• They do not supply constructors. Does this mean that no constructors are available? I'd hope not.
• They do not supply parameter types for methods that should clearly take parameters.
• They do not explain the purpose of particular methods. For example, what does getSeparator do?
• They do not use Javadoc comments for their fields.

Their code did not compile. (I've updated it so that it does.)

Although it became clear from discussion that their class would need to store information on ``preferred filters'', they have made no attempt to do so.

Some more specific comments:

• Zip codes should not be integers.
  • What do you do if the Postal code for another country uses letters?
  • What do you do about Postal codes with leading 0's? How do you distinguish "12345" from "00001-2345"?
• Phone numbers should not be integers.
  • What do you do about leading 0's?
  • Are you sure that integers give enough digits of precision?
• You did not take much care.
  • For example, PersonalProfile referred to StreeteAddress instead of StreetAddress.
  • Similarly, you named methods getSaveOutgoingMali.
• I'd strongly recommend that you use java.util.Date rather than SimpleDate.
  • I've made this change in the distributed file.
• Given that you have an Address class, it's not clear why setAddress returns a StreetAddress.
• It would be nice if you put everyone's full name in your class header.

Team Flamingo

Nothing turned in.

The Team Who Would Be King

Nothing turned in. However, since they were building the textual user interface, they were not required to turn anything in. The were, however, supposed to be prepared for discussion. We'll see how that goes.

History

11 October 1999

• Created. Comments on Team Bison and Team Emu

13 October 1999

• Added remaining comments.
• Added history section.