4.8 Attributes Versus Contained Classes
When designing a containment hierarchy, keep in mind that most classes have attributes. Most attributes are descriptive in nature: the color of a car, the weight of a fruit, the length of a house. These are not considered containment relationships, since the contained data does not have behavior associated with it. For example, which of the following sentences make sense?
An engine contains pistons.
An engine contains maximum horsepower.
An engine has pistons.
An engine has maximum horsepower.
Most people consider sentence number 2 to be inappropriate. Notice that the verb "to have" is less descriptive than the verb "to contain." Why is there a semantic difference between sentences 1 and 2? A piston has behavior and is therefore modeled as a class, while maximum horsepower is simply a descriptive attribute and has no behavior. In some cases, several pieces of data may be encapsulated together and still called an attribute. Consider the role of a bank card in the domain of the automatic teller machine. It encapsulates the account and pin number but has no meaningful behavior. At best, it defines get_account() and get_pin(), but we do not count gets and sets on descriptive attributes as meaningful behavior. Many object-oriented designers refer to this entity as an attribute. This extended definition causes some confusion, especially among MIS developers, who have a more restrictive definition of attribute. They often ask, "What is the bank card an attribute of?" The object-oriented designer responds, "The bank card is an attribute of the system."