Class 14: Project Discussion

Held Friday, September 17, 1999

Overview

Today, we will return to our project and consider more details about how the individual pieces interact and how we might group them into subprojects. This consideration will also involve some discussion of Java's interfaces.

Notes

• Assignment 2 is due today.
  • I will not grade this assignment as I believe you learn more from the doing than the grading.
  • I will, however, make an answer key available next week.
• I will do my best to return assignment 1 on Monday.
  • My untested Sample Solution is now available.
• We may have prospectives visiting today.
• Exam 1 is ready. It includes some stuff on arrays, so you may not be able to work on all of the questions until Monday.
• By next Wednesday, I'd like each
• I hope to see some of you at Monday's brown-bag CS film.
• When printing in the MathLAN, please print double-sided. The command is lp -pprinter -oduplex
  • Use the command in the dialog box that Netscape and other applications display when asking for a printer command.
  • Use the command with a file name in dtterm windows.

Contents

• The Mail Project
  • Development and Testing
• Detour: Interfaces
  • A Simple Mailbox Interface

Handouts

• Exam 1

Summary

• Project discussion, continued
  • Architecture revisited
  • Narratives
  • Interface Drawings
• Java's interfaces
• Possible visit from prospectives
• Assigned:
  • Exam 1 (due Friday, September 24, 1999)
  • Read J6

The Mail Project

• In our previous discussion (which you can find summarized in outline 9), we came up with something like the following for the initial architecture of our system:

                             +----------+
                      +------| Maildrop |----+ +-------------+
                      |      +----------+  +-+-| Text Client |
  +---------+   +---------+   +---------+  | | +-------------+
  | Servers |---| Network |---| Mailbox |--+ |              |
  +---------+   +---------+   +---------+  | | +-----+      |
                                   |       +-+-| GUI |      |
       +-------------+        +---------+      +-----+   +--------+
       | MailMessage |        | Folders |       | \------| Filter |
       +-------------+        +---------+       |        +--------+
                                                |
       +-------------+  +-------+      +---------------+
       | MsgInfoList |  | Prefs |      | Face Database |
       +-------------+  +-------+      +---------------+
  

• We're not responsible for the servers; just for connecting to and using them with existing protocols (IMAP, whatever Microsoft uses for its extended functionality).
• MailMessage, MsgInfoList, and Prefs are utility classes that will be shared by many of the other classes (or groups of classes).
• The GUI will necessarily have many pieces, including
  • An overview window
  • Composing windows
  • Message reading windows
  • Filter interface windows
  • ...
• Today, we'll try to tell stories about what happens at various steps and see what that tells us about the methods that each class will need.
  • The interfaces will guide our steps.
• We may also want to draw pictures of what we think the interfaces might look like.
• We will eventually segment to project into reasonable-size parts. Here are my initial categories:
  • Network
  • Mailbox
  • Message composer plus maildrop
  • Filters (including prioritization)
  • Textual interface
  • Graphical interface (exception message composer)
  • Face database
  • Utility classes

Development and Testing

• What happens when a group starts to build a part of the system and the related parts are not available?
  • Yes, this is certainly likely to happen.
• Each group will need to pre-specify the public methods (and fields, if there are any) of the classes it creates.
  • Groups should also specify what they expect other classes to provide.
• But what if you want to test your part without the other parts already in place?
  • Each group will also be responsible for building stub versions of their classes. These versions return something useful, but don't do any real work behind the scenes.
• For example, consider the following simple Mailbox class. (This is simpler than the one that we'll actually use.)

  /**
   * A stub for a simple mailbox class.
   *
   * @author Samuel A. Rebelsky
   * @version 1.0 of September 1999
   */
  public class Mailbox {
    /** 
     * Activate the mailbox.  To force it to throw an InvalidAccount
     * exception, use the empty password.  To force it to throw a
     * ServerError exception, use "root" as the account.
     */
    public void login(String account, String password)
      throws InvalidAccount, ServerError
    {
      if (password.equals("")) {
        throw new InvalidAccount();
      }
      if (account.equals("root")) {
        throw new ServerError();
      }
    } // login(String, String)
  
    /**
     * Get a list of messages. 
     */
    public MsgInfoList listMessages() {
      MsgInfoList messages = new MessageList();
      messages.add("353@alpha.com", "John Smith", "Testing", "1/1/99");
      messages.add("354@alpha.com", "Jack Smith", "Testing", "3/1/99");
      messages.add("354@beta.com", "Smith", "Testing", "1/1/98");
      messages.add("354@gamma.com", "Jack", "More Testing", "1/1/00");
      messages.add("000@gamma.com", "Zebra" "Stripes", "5/1/99");
      return messages;
    } // listMessages()
  
    /**
     * Get a message given the message ID.  If the message ID starts
     * with 0, throws an exceptions.
     */
    public MailMessage getMessage(String messageID) 
      throws MailException
    {
      if (messageID.charAt(0) == '0') {
        throw new MailException("Invalid message ID");
      }
      return new MailMessage(...);
    } // getMessage(String)
  
  } // class Mailbox
  

• Now, we can write programs that use this mailboxes without having a ``real'' mailbox class. While we won't be able to test every possible real situation, we'll be able to cover many of them.

Detour: Interfaces

• But how will we make the transition from stub classes to real classes?
• In effect, we'd like to formally separate the specification of a class from its implementation.
• Java provides two mechanisms for doing this separation: abstract classes and interfaces.
  • We'll focus on interfaces.
• An interface is simply a collection of routines that a class can agree to support.
• For example, we might decide to make our complex numbers, which are most likely a subclass of Number agree to provide a set of drawing routines.
• Similarly, we might decide that Line objects, which would most likely be a subclass of Polygon (or some such) would also provide "mathematical" operations (so that you could add, subtract, and compare lines).
• Interface declarations look remarkably like class declarations, except that
  • You use interface instead of class.
  • You cannot include fields in an interface.
  • You do not give bodies to your interface's methods
• A class agrees to implement all the routines in an interface by using the implements keyword, as in

  public class Complex 
    implements Drawable {
    // ...
  } // Complex
  

• If you implement more than one interface, separate them by commas.

  public class Complex
    implements Drawable, Number {
    // ...
  } // Complex
  

• Once you've defined an interface, you can treat interfaces as classes, at least in terms of providing variables. For example, the following should be perfectly legal

  Drawable d = new Complex();
  

• This is another example of polymorphism in action.

A Simple Mailbox Interface

• Here's the interface that we might then use.

  public interface Mailbox {
    public void login(String account, String password);
    public MsgInfoList listMessages();
    public MailMessage getMessage(String messageID);
  } // Mailbox()