Our design process has come a cropper with the problem of how does the distribution center know about items in an order and the address of the customer. Before I get to the problem, a quote from Grady Booch (not my favorite author) (page 229 of Object-Oriented Analysis and Design with Applications, second edition)
The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of he professional software engineer to know that no such panacea exists. Amateurs often want to follow cookbook steps; professionals know that right approaches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsibility for earlier misguided decisions. The amateur software engineer either ignores documentation all together, or follows a process that is documentation-driven, worrying more about how these paper products look to the customer than about the substance they contain. The professional acknowledges the importance of creating certain documents, but never does so at the expense of making sensible architectural innovations.
With this off his chest (and mine) he goes on to say that while object-oriented design is not cookbook, it is sufficiently well-defined to offer a predictable and repeatable process.
Let's look at the sequence of events in our course program. When we add new professors, there is no effect on the course list, only the list of professors changes. We can do anything to the course list and in this model it has no effect on the professor list. When we edit a professors information, if there is a name change, it will automatically occur in the course list because of the structure of the courses. If we delete a professor, we will have trouble since the reference to the professor's name is no longer available. Not only that the course list is no longer correct, because the professor is not longer correct.
The professor list knows nothing about the course list. This is done to simplify the need to know about the details of one class by another class. All that the course knows about the class Professor is the name field (which is a string). The course window will need to know more about the changes in a professor class if it is to keep the course list up to date. This window as well as the main window will act as a mediator. A mediator is a central class that knows enough to maintain communications between interactive classes.
Professors are deleted in the ProfWindow. This window will notify the main window, Week1_98ListBox of the change using a windows message. The main window has access to all of the windows, so it can call the function processDelete to CourseWindow that will update the CourseWindow and CourseList.
One problem we encounter is that windows messages have a limited ability to send data. The easiest way that I have discovered to indicate which professor has been deleted (or more complex alterations in other problems) is to store the latest deletion along with its original location in the class ProfList. This also allows any of the windows to cancel the change. If you were to decide that a change cannot take place because of an effect in another window, that window can cancel the change and all of the information to restore the data is still available.
The general process for creating and handling messages is presented in a simple problem in my Borland HTML document. We will apply this technique in our course problem. For details of this click here.