9.13. Guideline: When to Model with 'Description' Classes?
A description class contains information that describes something else. For example, a ProductDescription that records the price, picture, and text description of an Item . This was first named the Item-Descriptor pattern in [Coad92].
Motivation: Why Use 'Description' Classes?
The following discussion may at first seem related to a rare, highly specialized issue. However, it turns out that the need for description classes is common in many domain models.Assume the following:
- An Item instance represents a physical item in a store; as such, it may even have a serial number.
- An Item has a description, price, and itemID, which are not recorded anywhere else.
- Everyone working in the store has amnesia.
- Every time a real physical item is sold, a corresponding software instance of Item is deleted from "software land."
With these assumptions, what happens in the following scenario?There is strong demand for the popular new vegetarian burgerObjectBurger. The store sells out, implying that all Item instances of ObjectBurgers are deleted from computer memory.Now, here is one problem: If someone asks, "How much do ObjectBurgers cost?", no one can answer, because the memory of their price was attached to inventoried instances, which were deleted as they were sold.Here are some related problems: The model, if implemented in software similar to the domain model, has duplicate data, is space-inefficient, and error-prone (due to replicated information) because the description, price, and itemID are duplicated for every Item instance of the same product.The preceding problem illustrates the need for objects that are descriptions (sometimes called specifications ) of other things. To solve the Item problem, what is needed is a ProductDescription class that records information about items. A ProductDescription does not represent an Item , it represents a description of information about items. See Figure 9.9.
Figure 9.9. Descriptions about other things. The * means a multiplicity of "many." It indicates that one
ProductDescription may describe many (*) Items .Guideline: When Are Description Classes Useful?
Guideline Add a description class (for example, ProductDescription ) when:
|
Example: Descriptions in the Airline Domain
As another example, consider an airline company that suffers a fatal crash of one of its planes. Assume that all the flights are cancelled for six months pending completion of an investigation. Also assume that when flights are cancelled, their corresponding Flight software objects are deleted from computer memory. Therefore, after the crash, all Flight software objects are deleted.If the only record of what airport a flight goes to is in the Flight software instances, which represent specific flights for a particular date and time, then there is no longer a record of what flight routes the airline has.The problem can be solved, both from a purely conceptual perspective in a domain model and from a software perspective in the software designs, with a FlightDescription that describes a flight and its route, even when a particular flight is not scheduled (see Figure 9.10).