Previous | Table of Contents | Next |
Not all classes within a generalization hierarchy will have objects associated with them. The object-oriented paradigm allows for abstraction, which means that a class may exist only for the purpose of passing inherited data and behaviors. The classes VEHICLE and CAR would probably not have any concrete objects, while objects within the VAN class would inherit from the abstract VEHICLE and CAR classes. Multiple inheritance is also demonstrated by the AMPHIBIAN_CAR class. Any instances of this class will inherit data and behaviors from both the CAR and the BOAT classes.
It is important to note the tremendous difference between one-to-many relationships and ISA relationships. In the above example, this entire class hierarchy describes vehicles that are associated with the ITEM entity in the overall database. Class hierarchies do not imply any data relationships between the classes. While one CUSTOMER may place many ORDERs, it is not true that one CAR may have many SEDANs.
Polymorphism
Polymorphism is the ability of different objects to receive the same message and behave in different ways. This concept has many parallels in the real world. An event, such as a volcanic eruption, may have many different effects on the living things in the area: The poisonous gases may kill all air-breathing animals, while at the same time nourish the small marine organisms nearby. The single behavior of ERUPTION has had different effects upon objects within the ANIMAL class. Another analogy can be found in the business world: For a personnel manager, the event of PROMOTION will cause different behaviors depending upon the class of EMPLOYEE that receives the PROMOTION. MANAGEMENT objects will receive stock options and country club memberships, which are not offered to JANITOR objects.
Ronald Popeil was a master of polymorphism. Many folks remember the heyday of Ronco and Popeil, where polymorphic products were advertised at the national level. Consider the statement Its a hair cream AND a floor wax. If this is indeed true, the method spread_it_on would invoke very different processes depending upon whether we are applying the cream to a floor or a persons head.
The concept of polymorphism originally came from the programming concept of overloading. Overloading refers to the ability of a programming function to perform more than one type of operation depending upon the context in which the function is used. For example, consider the following Basic program:
REM Sample Basic program to show polymorphism REM Increment the counter COUNTER = COUNTER + 1 REM Concatenate the String N$ = "Mr. Burleson" S$ = "Hello there, " + N$ END
In this example, the operator + is used to indicate addition in one context and concatenation in another context. But what determines the way that the operator will function? Clearly, the Basic compiler knows that the + operator means addition when it is used in the context where a number is passed as an argument, and it knows that concatenation is required when character strings are passed as an argument to the operator.
The implications of polymorphism are that a standard interface may be created for a related group of objects. The specific action performed by the object will depend upon the message that is passed to the interface. Because the programmer is no longer concerned with the internal constructs of the object, extremely complex programs can be created. The programmer only needs to understand the interface to use the object.
In the real world, polymorphism can be described by looking at standard interfaces. In most PC-based software, the F1 key has a special meaning. Pressing F1 will invoke a context-sensitive help function and explain the function to the user. These help functions have vastly different methods and different data storage techniques, but the standard interface (F1) is polymorphic and invokes different internal mechanisms depending upon the software.
Another example is the controls on an automobile. While the internal workings of automobiles are vastly different, the steering wheels are always round and the gas petal is always to the right of the brake. These polymorphic interfaces make it possible for any person to drive a car without being concerned with the underlying structures of the vehicle.
All communication between objects and their behaviors is accomplished with messages that are passed as behaviors. For example, consider the two objects of rush_order and cod_order belonging to the ORDER class.
When a message such as prepare_invoice is called, it may contain sub-behaviors such as prepare_invoice and compute_charges (see Figure 2.9). The message prepare_invoice directs the system to compute the shipping changes. Different procedures will then be invoked depending upon whether the receiving object is a rush_order object or a cod_order objecteven they are both objects within the ORDER class. A rush order would include overnight mail calculations, while the COD order would contain additional computations for the total amount due. This is equivalent to the following procedural language code.
Figure 2.9 An example of polymorphism.
Here we see an illustration of the differences between an object-oriented procedure call (a message) and the procedural language equivalent:
place_order(prepare_invoice(compute_charges))
IF (rush_order) COMPUTE SHIPPING = TOT_AMNT * .25 ELSE COMPUTE SHIPPING = TOT_AMNT * .10 IF (cod_order) COMPUTE TOT_DUE = TOT_AMNT + SHIPPING ELSE COMPUTE TOT_DUE = 0
Encapsulation
Encapsulation means that each object within the system has a well-defined interface with distinct borders. In plain English, encapsulation refers to the localized variables that may be used within an object behavior, and cannot be referenced outside of that behavior. This closely parallels the concept of information hiding. Encapsulation also ensures that all updates to the database are performed by using (or by way of) the behaviors associated with the database objects.
Previous | Table of Contents | Next |