|
|
|
|
|
|
|
It is the pAddress object's job to keep track of both the display string and the internal routing string for its service. One open question for your design is whether there should be one pAddress object, or if it should be subclassed for each service type. For now the service is tracked as an enumerated constant that is a member variable of each pAddress object. |
|
|
|
|
|
|
|
|
Lines 193226 show the interface to the PostMasterMessage class. In this particular listing, this class stands on its own, but very soon you'll want to make this part of its inheritance hierarchy. When you do redesign this to inherit from Message, some of the member variables may move into the base classes, and some of the member functions may become overrides of base class methods. |
|
|
|
|
|
|
|
|
A variety of other constructors, accessor functions, and other member functions will be required to make this class fully functional. Note that what this listing illustrates is that your class does not have to be 100% complete before you can write a simple driver program to test some of your assumptions. |
|
|
|
|
|
|
|
|
On lines 244247, the Edit() function is stubbed out in just enough detail to indicate where the editing functionality will be put once this class is fully operational. |
|
|
|
|
|
|
|
|
Lines 250260 represent the driver program. Currently this program does nothing more than exercise a few of the accessor functions and the operator<< overload. Nonetheless, this gives you the starting point for experimenting with PostMasterMessages and a framework within which you can modify these classes and examine the impact. |
|
|
|
|
|
|
|
|
In this hour you saw how to bring together many of the elements of C++ syntax and apply them to object-oriented analysis, design, and programming. The development cycle is not a linear progression from clean analysis through design and culminating in programming; rather, it is, in fact, cyclical. The first phase is typically analysis of the problem, with the results of that analysis forming the basis for the preliminary design. |
|
|
|
|
|
|
|
|
Once a preliminary design is complete, programming can begin; but the lessons learned during the programming phase are fed back into the analysis and design. As programming progresses, testing and then debugging begin. The cycle continues, never really ending, although discrete points are reached. There comes a time, however, when it is appropriate to ship the product. Don't hesitate, ship it! |
|
|
|
|
|
|
|
|
When analyzing a large problem from an object-oriented viewpoint, the interacting parts of the problem are often the objects of the preliminary design. The designer keeps an eye out for process, hoping to encapsulate discrete activities into objects whenever possible. |
|
|
|
|
|