Previous Section Main Menu Next Section

CHAPTER 8

AN EVEN BETTER CONTRACT PROGRAM


Section IV: Lists: Working with Encapsulation Section I: Analyzing the Code Implications of an Improved Contract Program Section II:Instances as Array Elements Section III: The List: A Look at Data Representation
Section V: Class Declarations for Contract and ListOfContracts Section VI: Member Functions for ListOfContracts Section VII: Improving ListOfContracts Section VIII: Rewriting the Nonmember Functions

Section IV. Lists: Working With Encapsulation
The previous section described three problems with our design of 'ListOfContracts'. First, if we are to display a contract, we need to have access to that contract; second, if we are to modify a contract, we need to again have access to that contract; and third, if we are to display all the contracts, we need to have access to all the contracts without knowing the contract ID's for individual contracts.

Two general approaches seem to exist for solving these problems. Note that the key issue is access to the contracts in the list. One answer would be to have the class 'ListOfContracts' do all the work. That is, we could declare the functions 'DisplayInfo', 'ChangeInfo' and 'DisplayAll' as member functions of 'ListOfContracts'. This would work because any member function of 'ListOfContracts' has access to the array. However, many software engineers would be uncomfortable forcing a class whose purpose is to handle list processing to handle changes to individual elements of the list.

A second solution would be to add a new member function to the 'ListOfContracts' class. This function would receive a contract ID and return either a contract (if one exists with the desired ID) or some kind of failure indicator. If we do this, we will also need a member function to replace a contract after it has been changed. This solution handles the first two problems because it provides access to individual contracts but does nothing to fix 'DisplayAll'. We could provide a member function that returns the contracts one at a time when some function in the main program says 'next'. This would work but is getting quite complex.

How about a compromise! The 'DisplayAll' function does seem to be appropriate as a member function of 'ListOfContracts', since it involves the whole list. Therefore, the second solution could be used for the 'DisplayInfo' and ChangeInfo' functions, while 'DisplayAll' becomes a member function of 'ListOfContracts'. In other words, 'DisplayInfo' and ChangeInfo' would remain part of the main program (with 'ListOfContracts' providing functions to return and replace contracts), while 'ListOfContracts' would take on the responsibility of displaying all the contracts. Some software engineers might argue that we have arbitrarily split the functionality here but that is the approach we shall use.

It seems then that we have discovered three new responsibilities for the 'ListOfContracts' class:

Here is a modified CRC card:


That finishes the design stage. Hopefully, you are becoming aware of the fact that this process is not cut and dried and that there are many ways to accomplish the same goals. As you work on more complex problems, you will find that members of the design team do not always agree about what kinds of classes are needed, their relationships to each other, as well as their knowledge and behavioral responsibilities. The real world is not so clean cut. One author of this text remembers spending a whole week-end negotiating with two associates about the design for a game they were going to develop. And, even then, the design they came up with was changed in a year!

Top of Section Main Menu Next Section