|
|
|
|
|
|
|
The message editors will be tempted to create editors with an intimate knowledge of the internals of the message class, but this would be a bad design mistake. They too must negotiate a very narrow interface to the message class; message editor objects should know very little about the internal structure of messages. |
|
|
|
|
|
|
|
|
Ongoing Design Considerations. |
|
|
|
|
|
|
|
|
As the project continues, you will repeatedly confront this basic design issue: in which class should you put a given set of functionality (or information)? Should the message class have this function, or should the address class? Should the editor store this information, or should the message store it itself? |
|
|
|
|
|
|
|
|
Your classes should operate on a need-to-know basis, much like secret agents. They shouldn't share any more knowledge than is absolutely necessary. |
|
|
|
|
|
|
|
|
As you progress with your program, you will face hundreds of design issues. They will range from the more global questions, What do we want this to do? to the more specific, How do we make this work? |
|
|
|
|
|
|
|
|
Although the details of your implementation won't be finalized until you ship the code, and some of the interfaces will continue to shift and change as you work, you must ensure that your design is well understood early in the process. It is imperative that you know what you are trying to build before you write the code. The single most frequent cause of software dying on the vine must be that there is not sufficient agreement, early enough in the process, about what is being built. |
|
|
|
|
|
|
|
|
To get a feel for what the design process is like, examine this question, What will be on the menu? For PostMaster, the first choice is probably New Mail Message, and this immediately raises another design issue: When the user selects New Mail Message, what happens? Does an editor get created, which in turn creates a mail message, or does a new mail message get created, which then creates the editor? |
|
|
|
|
|
|
|
|
The command you are working with is New Mail Message, so creating a new mail message seems like the obvious thing to do. But what happens if the user clicks Cancel after starting to write the message? Perhaps it would be cleaner to first create the editor and have it create (and own) the new message. |
|
|
|
|
|
|
|
|
The problem with this approach is that the editor will need to act differently if it is creating a message than if it were editing the message; whereas if the message is created first, and then handed to the editor, only one set of code needs to exist because everything is an edit of an existing message. |
|
|
|
|
|