Design Patterns Explained

296 Part V • Handling Variations with Design Patterns
4. Use the rows to
identify rules
A note about customers.
My experience with customers has taught me several things:
• They usually know their problem domain very well (most
know it better than I ever will).
• In general, they do not express things on the conceptual
level, as developers often do. Instead, they talk in specific
cases.
• They often use the term always when they mean usually.
• They often use the term never when they mean seldom.
• They often say they have told me about all of the cases when
in fact they have only told me what usually happens.
The bottom line is that I trust customers to tell me what happens
when I ask specific questions but I do not trust their generalized
answers. I try to interact with them at a very concrete level. Even
those customers who sound like they think in a conceptual way
often do not, but are trying to "help me out."
Now that the concepts are revealed, what should I do with what I
know? How do I begin to move toward implementation?
Look at the matrix in Table 20-6. The first row is labeled "Calculate
freight," and includes "Use UPS rates," "Use Canadian shipper,"
and "Use German shipper." This row represents both
• A general rule to implement "Calculate freight rate"
• The specific set of rules that I must implement— that is, each
shipper I may use in the different countries
In fact, each row represents specific ways of implementing a generalized
concept. Two of the rows (money and dates) may be handled at
the object level. For example, money can be handled with objects