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 “It’s 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 person’s 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 object—even 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:

  Object-oriented call:
    place_order(prepare_invoice(compute_charges))
  Procedural language equivalent:
    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