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." |