|
|
|
|
|
|
|
An examination of the various email formats reveals that they have many things in common, despite their various differences. Each email message has a point of origination, a destination, and a creation date. Nearly all such messages have a title or subject line, and a body that may consist of simple text, rich text (text with formatting), graphics, and perhaps even sound or other fancy additions. Most such email services also support attachments so that users can send programs and other files. |
|
|
|
|
|
|
|
|
You confirm your early decision that you will read each mail message out of its original format and into PostMaster format. This way you will only have to store one record format, and writing to and reading from the disk will be simplified. You also decide to separate the header information (sender, recipient, date, title, and so on) from the body of the message. Often the user will want to scan the headers without necessarily reading the contents of all the messages. You anticipate that a time may come when users will want to download only the headers from the message provider, without getting the text at all, but for now you intend that version one of PostMaster will always get the full message, although it may not display it to the user. |
|
|
|
|
|
|
|
|
This analysis of the messages leads you to design the Message class. In anticipation of extending the program to non-email messages, you derive EmailMessage from the abstract base Message. From EmailMessage you derive PostMasterMessage, InterchangeMessage, CISMessage, ProdigyMessage, and so forth. |
|
|
|
|
|
|
|
|
Messages are a natural choice for objects in a program handling mail messages, but finding all the right objects in a complex system is the single greatest challenge of object-oriented programming. In some cases, such as with messages, the primary objects seem to fall out of your understanding of the problem. More often, however, you have to think long and hard about what you are trying to accomplish to find the right objects. |
|
|
|
|
|
|
|
|
Don't despair. Most designs are not perfect the first time. A good starting point is to describe the problem out loud. Make a list of all the nouns and verbs you use when describing the project. The nouns are good candidates for objects. The verbs might be the methods of those objects (or they may be objects in their own right). This is not a fool-proof method, but it is a good technique to use when getting started on your design. |
|
|
|
|
|
|
|
|
That was the easy part. Now the question arises, Should the message header be a separate class from the body? If so, do you need parallel hierarchiesCompuServeBody and CompuServeHeader as well as ProdigyBody and ProdigyHeader? |
|
|
|
|
|
|
|
|
Parallel hierarchies are often a warning sign of a bad design. It is a common error in object-oriented design to have a set of objects in one hierarchy and a matching set of manager objects in another. The burden of keeping these hierarchies up-to-date and in synch with each other soon becomes overwhelming: a classic maintenance nightmare. |
|
|
|
|
|