13.2. The Language of the Client

 <  Day Day Up  >  

Sam came by to discuss the discount mechanism that he was thinking about. He started talking. I was listening with a pen in hand. He said something like this:

"I want to give a 5% discount if a customer rented more than six CDDiscs in the past month and another 5% if he averaged more than five rentals in the last six months," he said, without pausing for a breath .

"Say again," I asked.

He replied at the same speed, as though he thought that if he did not get it out fast enough, he would forget it.

I took out a clean sheet of paper and copied down what I was pretty sure I heard :

Start with discount_percentage = 0.0.

Compute number_of_rentals_in_last_month:

Compute average_number_of_rentals_during_last_six_months:

If (average_number_of_rentals_during_last_six_months > 5) discount_percentage = discount_percentage + 5.0

I asked him if this was what he meant . He looked at it and asked what the > symbol meant.

I told him that it meant, "is greater than."

He said, "Great, that's exactly what I want."

"Is this what you'll want forever?" I asked.

"Well, probably not," he replied.

"I'll tell you what; I'm going to let you maintain this code," I said. "If those numbers change, you just change the numbers and I'll add it to the program."

"So I'm a programmer now?" Sam asked.

"Of course. We're part of a team," I replied.

Suppose Sam were fairly sure that the algorithm was not going to change, but the numbers were going to change. Then a configuration file would be appropriate. The values could be set in a dialog box and then written to that file. The algorithm would look like this:

Start with discount_percentage = 0.0.

Compute number_of_rentals_in_last_month:

if (number_of_rentals_in_last_month > NUMBER_LAST_MONTH_RENTALS_FOR_DISCOUNT) discount_percentage = DISCOUNT_FOR_EXCEEDING_LAST_MONTH_RENTAL_LEVEL

Compute average_number_of_rentals_during_last_six_months:

if (average_number_of_rentals_during_last_six_months > NUMBER_SIX_MONTH_RENTALS_FOR_DISCOUNT) discount_percentage = discount_percentage + DISCOUNT_FOR_EXCEEDING_SIX_MONTH_RENTAL_LEVEL:

Every variable in capital letters would have a corresponding entry in a configuration file. The configuration file in XML might look like this:

 <number_last_month_rentals_for_discount>6         </number_last_month_rentals_for_discount> 

If the algorithm were subject to additional changes, it is often easier to let the client be responsible for those changes. The developer's job is to provide the methods needed to perform the data gathering and computations needed by the client. For example, Tim and I might create more-general data-gathering methods, such as the following:

 compute_average_number_of_rentals_during_previous_months(int number_of_months)     compute_total_number_of_rentals_during_previous_months(int number_of_months) 

Sam could alter the number of months without contacting us. If Sam or his staff is maintaining the code and the indirection of using named constants was confusing, actual values might appear in the code. The code that he maintains might look like this:

 Dollar compute_discount( )         {         Dollar discount_percentage = 0.0;         number_of_rentals_in_last_month =             compute_total_number_of_rentals_during_previous_months (1);         if (number_of_rentals_in_last_month > 5)             discount_percentage = 5.0;         average_number_of_rentals_during_previous_months =             compute_average_number_of_rentals_during_previous_months (6)         if (average_number_of_rentals_during_previous_months > 5)             discount_percentage = discount_percentage + 5.0;         return discount_percentage;         } 

To the average programmer, this code seems a bit wordy. To Sam, it is understandable. These methods become a domain language for computing the customer discount. Even if Sam does not maintain the code himself, the code expresses his desires in his terms. He can look at the code to see whether it accurately reflects his business policies.

USE THE CLIENT'S LANGUAGE

Use the client's language in your code to make it easier to compare the logic in the code to the logic of the client . [*]


[*] A reviewer suggested that this is a concept in domain-driven programming. See Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (Addison-Wesley Professional, 2003).

TYPE OR PRESS

Many years ago, I had a client who could never make up his mind whether a prompt should read, "Type any key to continue" or "Press any key to continue." For every release, he would switch his decision. Finally, I sent him a file that contained one of the phrases. I told him, "If you want to make a change, just enter it in that file, and send it back to me." The program incorporated that file as one of the source files for the executable. For further flexibility, the program could have read a file at startup time for the desired phrase. However, the client wanted to distribute only a single file.

The client was happy. He could make his own changes. So I was happy.


Business rules, such as for the customer discount, are rules created by businesspeople: those in finance, marketing, and other areas. Business rules can involve the price you charge for a product, the discount you give to customers, the action to take when an invoice is overdue, and so forth. The details of business rules can change frequently. Whether to create a separate class for business rules is another example of the "The Spreadsheet Conundrum". The compute_discount( ) method can go into the Customer class, since it relates to that class. However, the method could be put into a BusinessRules class to gather methods that a client is particularly interested in and that might change frequently.

If the business rules are complex, you can use a business rules language such as ILOG JRules, the open source Mandarax, or the Business Rules Markup Language (BRML). [ ]

[ ] Scott Ambler explains how business rules are another model at http://www.agilemodeling.com/principles.htm.

BUSINESS RULES ARE A BUSINESS UNTO THEMSELVES

Keep business rules separate from other logic .


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net