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].
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.
ProductDescription may describe many (*)
Items .
A particular
Item may have a serial number; it represents a physical instance. A
ProductDescription wouldn't have a serial number.
Switching from a conceptual to a software perspective, note that even if all inventoried items are sold and their corresponding
Item software instances are deleted, the
ProductDescription still remains.
The need for description classes is common in sales, product, and service domains. It is also common in manufacturing, which requires a
description of a manufactured thing that is distinct from the thing itself.
|
Guideline Add a description class (for example, ProductDescription ) when:
|
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).
Note that the prior example is about a service (a flight) rather than a good (such as a veggieburger). Descriptions of services or service plans are commonly needed.
As another example, a mobile phone company sells packages such as "bronze," "gold," and so forth. It is necessary to have the concept of a description of the package (a kind of service plan describing rates per minute, wireless Internet content, the cost, and so forth) separate from the concept of an actual sold package (such as "gold package sold to Craig Larman on Jan. 1, 2047 at $55 per month"). Marketing needs to define and record this service plan or
MobileCommunicationsPackageDescription before any are sold.