cs1ch10sec5.htm
 CHAPTER 10

ANOTHER VISIT WITH THE CONTRACT PROGRAM
OR
WORKING WITH DYNAMICALLY SIZED LISTS
 
Section V: Adding String Properties to the Contract Class Section I: An Expandable List of Contracts Section II: Declaring the New ListofContracts Section III: Defining the New ListOfContracts
Section IV : Re-Evaluating the Contract Program Design Section VI: Declaring the New Contract Class Section VII: Defining the New Contract Class Section VIII: Modifying the Main Program

  


Table of Contents

Learning C++:
An Index of Entry Points

2. The

of C++

A reference document on the basic elements of C++.


3. The Patterns

In all the previous descriptions of the contract program, the authors were careful to avoid any mention of names, addresses, or any other data type that would require a string. Imagine that we as programmers have shown the first version of our program to Olympia and she has complained about inability to the handle the name of the person handling the contract and the address of the office to be cleaned. We might go back to the office and rewrite the problem narrative as follows:

    Olympia owns a small office cleaning business. She wishes to have a program to keep track of the contracts she has with various businesses. Each contract involves one office complex and should keep track of the square footage of the office, the number of desks in the office, and the number of days per week the office is to be cleaned. Additional information in each contract includes the name of the person contracted with (the contractee) and the address of the office to be cleaned. A user of this program should be able to change any of this information and get the per week charge based on the formula:

      Weekly Charge = Days per Week * ($0.05 per square feet + $5 per desk)

    Users should also be able to add new contracts and delete existing ones. When adding contracts, the contract ID, the contractee's name, the square footage of the office, the number of desks in the office, and the number of days per week the office is to be cleaned all must be provided. The office address can be provided initially or added later. To delete a contract, the user enters the contract ID.

We have been skipping the program interface analysis in the last few modifications of this program but enough new material has been added that it is time to revisit this issue. Take your time and play with this for a bit. Then, continue with the paragraph below

***************************************

Now that you are finished with your interface analysis, compare your conclusions with those below. Remember, that there are many possible 'correct answers' but some may be more elegant, efficient, or easier to use than others.

One of the things that you may have noticed is that as more properties are added, the output of those properties may need to be consolidated and organized more cleanly. One way to handle this might be to imagine a screen layout for the information on each contract. For example:

                                    Contract ID

    Contractee Name:     ..............................................


    Office Address:      ..............................................


                         ..............................................                       

                                                                        
The square footage:   ....................      The number of desks:   ..................


The number of days:   ....................      The per week charge:   ..................
Another thing you may have noticed is that it is getting awkward to input information for contract changes. If the user wants to make a large number of changes, it can take a while - not so much to enter the actual changes, as that can't be avoided, but to make the requests. One way to speed things up is to have a menu as before but allow the user to enter at once the codes for all the fields to be changed. The menu might look as follows:

"Please enter the codes corresponding to the properties you want to change";

"Enter as many as you desire. When finished, hit Enter.";

    '1': Contractee Name;
    '2': Office Street Address;
    '3': Office City;
    '4': Office State;
    '5': Office Zip;
    '6': square Footage;
    '7': number of desks;
    '8': number of days per week;

You could not have written code to handle this before because you did not know how to handle strings. Now you are ready for the big time. One thing you might stop to consider at this point is just how important a good program interface is to the success of a piece of software. That is probably one of the criteria you, yourself, use in evaluating software. Of course, your criteria probably include issues involving windows and the use of input devices such as mice or joy sticks. We are avoiding those issues here but they are just variations on the theme.

All we have discussed here is part of an improved program interface that needs to be incorporated into the program specifications. In Chapter 6 we developed a simple interface. Below is a modified interface, reflecting the modifications we have discussed: 

Interface:
An Introductory Screen:
	"W E L CO M E   TO   O L Y M P I A 
	O F F I C E   C O N T R A C T   P R O G R A M"

An Exit Screen:
	"Some Appropriate Message"

Inputs:
All inputs come from a user at a keyboard
1. User Option Menu:
     "Please choose one of the following operations
	'D' to display the information for a contract
        'L' to display the information on ALL contracts
	'C' to change the information for a contract
	'A' to add a contract to the list
	'E' to eliminate a contract from the list
	'Q' to quit the program"
   Input: <choice>, a character

2. Prompt: "Please enter the ID for the contract you wish to work with.
            Choose 0 (zero) when you are finished with this operation."
   Input:  <contract number>, an integer 

3. Change Contract Menu:
     "Please enter the codes corresponding to the properties you want to change";
     "Enter as many as you desire. When finished, hit Enter.";

        '1':  Contractee Name;
	'2':  Office Street Address;
	'3':  Office City;
        '4':  Office State;
        '5':  Office Zip;
        '6':  square Footage;
        '7':  number of desks;
        '8':  number of days per week;
   Input: <choices>, a string of characters

4. Prompt: "What is the new square footage for the contract?"
   Input:     <square footage>, a integer;

5. Similar prompts and integer inputs for the number of desks and number of days

6. "Please enter the new …." (Fill in with appropriate contract property name,
                                  for example, 'Office Street Address'.)
    Input: <property>, a string of up to 80 characters

7. Prompt: "Do you want to really want top quit (Y) or (N)?"
   Input:   <choice>, a character

Outputs:
All outputs are to the screen:

                                    Contract ID

    Contractee Name:     ..............................................


    Office Address:      ..............................................


                         ..............................................                       

                                                                        
The square footage:   ....................      The number of desks:   ..................


The number of days:   ....................      The per week charge:   ..................
 

Now that we have come up with a better program interface, we move onto the class analysis. The question is: Have the changes we have made required any new classes be added to the program, or do they simply require new or modified data and function members in existing classes? To answer this, the first step again is to underline and circle.

    Olympia owns a small office cleaning business. She wishes to have a program to keep track of the contracts she has with various businesses. Each contract involves one office complex and should keep track of the square footage of the office, the number of desks in the office, and the number of days per week the office is to be cleaned. Additional information in each contract includes the name of the person contracted with (the contractee), and the address of the office. A user of this program should be able to change any of this information and get all of it plus the per week charge which is calculated based on the formula:

      Weekly Charge = Days per Week * ($0.05 per square feet + $5 per desk)

    Users should also be able to add new contracts and delete existing ones. . When adding contracts the contract ID, the contractee's name, the square footage of the office, the number of desks in the office, and the number of days per week the office is to be cleaned all must be provided. The office address can be provided initially or added later. To delete a contract, the user enters the contract ID.

This time we come up with one new verb, 'includes', and five new nouns - 'information', 'person', 'name' (of the person), 'contractee', and 'address' (of the office).

The verb 'includes' and the noun 'information' can be ignored for the same reason we ignored the verb 'provided' in chapter 8. Again, we are dealing with English phrasing here. All programs deal with "information" and the act of 'including' information is a description of an action performed by almost all objects automatically - by having properties. In saying that contracts have or include certain information, the narrative is simply stating that instances of the class have certain properties (data members), but it is stating nothing about the actions of contracts. As has already been said, object-oriented analysis and design is, in part, an art form requiring good common sense. You will become better at the process, the more you practice it, BUT whatever you do, make sure you use your own common sense.

The next noun is 'person'. Remember the issues here: Is 'person' a new element in the design? If so, is it a class or a property of some class? The answers to these questions require a careful analysis, an analysis that can be tricky. Using our common sense we say that persons exist as separate 'things'. They are not a property of some other thing. We are led to believe then that 'person' might be a new class in this program. However, look carefully at the problem. Does the problem concern itself in any way with persons other than as contractee's of contracts? In other words, do 'persons' exist separate from contracts? In this program it does not seem that they do. There are no actions or responsibilities uniquely related to persons and no properties of persons other than those related to contracts.

We could imagine a different problem where people 'existed' separate from contracts and performed actions or had their own responsibilities. For example, if the problem involved professional baseball players and each player-person had not only a contract but various properties related to baseball statistics we would need a separate class.

The upshot then is that 'person' in this problem narrative is another one of those words that we can ignore. In coming to this conclusion we can also say the same thing about 'contractee' since 'contractee's in this problem really are persons under a different name.

The final two words in the list (name and address) are important. They clearly refer to properties of a contract - each contract includes a name and an office address. Thus, we have two more properties to add to our class declaration. We also have more member functions since these are properties that users of this class will want to access and modify. Note that an address really refers to a number of data items. While we could have one data member for the address that included the street address, the city, the state, and the zip code, it would be difficult then to only access one part of the address, for example, the state. Therefore, when we implement the address property, we will actually create separate data members for each element of the address.

That completes our analysis as it relates to the 'Contract' class. Since we have added two new properties that are accessible and modifiable by users, we need to add two new knowledge responsibilities and four new behaviors to the CRC card for this class. The card, therefore, looks as follows:

Figure 10.10

While there are no new verbs in the problem narrative related to the "ListOfContracts" class, we know from earlier discussion that it has new responsibilities. Figure 11.11 shows the modified CRC card for this class.

It is now time to move to the implementation phase. As we do so, be aware that the analysis and design phases focus on what properties and responsibilities or behaviors are required in each class and say nothing about HOW those properties and responsibilities are implemented. We will discover that more changes need to be made than have been mentioned - primarily because of the way C++ handles strings.

Top of Section Main Menu Next Section