Inheritance

Understanding Object Inheritance

Consider a simple database used by a courier company. It contains registration information for three types of vehicles: trucks, cars, and bicycles. For each vehicle type, your application requires the following information:

• VID (Vehicle Identification)

• LastMaint (mileage since last maintenance)

• LoadCap (load capacity)

If these are all the attributes shared by all vehicles in the application, then these attributes must all appear in the super class, Vehicle. You can then build subclasses for each of the vehicle types that reflects their differences. For example, the Truck class may have an attribute indicating whether the local department of transportation considers it to be a commercial vehicle (NumAxles), the Car class may require a NumPass (number of passengers) attribute, and the Bicycle class, by virtue of its more limited range, may require a Location attribute. Through inheritance, each vehicle automatically inherits the basic vehicle information, but by being separate subclasses, also have unique characteristics.

Figure 3-6 Inheritance in a Courier Application

Description of the illustration inhrex.gif

Representing Inheritance in the Database

You can represent inheritance in the database in one of two ways:

• Multiple tables that represent the parent class and each child class

• A single table that comprises the parent and all child classes

Figure 3-7 Inheritance in the Database in Individual Tables

Description of the illustration dbinhrt1.gif

If your database already represents the objects in the inheritance hierarchy this way, you can map the objects and relationships without modifying the tables. However, it is most efficient to represent all classes from a given inheritance hierarchy in a single table, because it substantially reduces the number of table reads and eliminates joins when querying on objects in the hierarchy.

Figure 3-8 Inheritance in the Database in a Single Table

Description of the illustration dbinhrt2.gif

To consolidate tables in the database this way, determine the class type of the objects represented by the rows in the table. There are two ways to determine class type:

• If you can add columns to the database table, add a class indicator column that represents the vehicle class type (Truck, Car, or Bicycle).

  For more information about class indicators, see "Class Indicators".

• If you cannot modify the table, build a class extraction method that executes an appropriate login to determine the class type.

  For more information about class extraction methods, see "Class Extraction Methods".

Class Types

The OracleAS TopLink inheritance hierarchy includes three types of classes:

• Root Class

• Branch Class

• Leaf Class

Figure 3-9 Inheritance Hierarchy Class Types

Description of the illustration rtbrlf.gif

Class Indicators

A class indicator is a mechanism for determining the class or type of an object. For example, a Person table may include an indication of whether the person represented by the table row is an Employee or a Manager. Use the class indicator to select the appropriate subclass to be instantiated from a set of available subclasses.

Class Extraction Methods

Class extraction enables you to determine the correct class type to instantiate from a table that includes several classes. Unlike a class indicator, however, a class extraction method does not rely on a single column in the table to determine class type. Instead, you can apply logic to the information in several fields to determine class type.

This method is useful when you use a legacy database with a new application. Table 3-1 illustrates a sample use of the class extraction method.

The inheritance hierarchy is designed such that Employee is the root class, and Director is a branch class that inherits from Employee. All employees, other than directors, are represented as instances of Employee, but directors must be represented by an instance of the Director class. Because values other than 2 can appear in the JOB_TYPE field, you cannot use the class indicator mechanism of OracleAS TopLink for mapping this data.

To resolve this, add a class extraction method to the root class, Employee. The method executes custom logic to determine the correct class to instantiate. The method is static, returns a Class object, and takes DatabaseRow as a single parameter.

// Return the Director class for TYPE values of 2,
// Employee class for any other value

public static Class getClassFromRow(DatabaseRow row) {
    if (row.get("JOB_TYPE").equals(new Integer(2)) {
        return Director.class;
    }
    else { return Employee.class;
    }
}

Although there is no direct indication of vehicle type in the data, you can build logic into a class extraction method to infer the vehicle type. This is made easier if you are familiar with the available types in the database. In this example, you can use a class extraction method to implement the following logic:

• If NumberOfAxles is greater than 2, then return the class HeavyTruck.

• If NumberOfAxles is 2 or less and GrossVehicleWeight is greater than 1000, then return the class type PassengerVehicle.

• In all other cases, return the class Motorcycle.

public static Class getClassFromRow(DatabaseRow row) {
    if (row.get("NumberOfAxles").intValue()>2){
        return HeavyTruck.class;
    }
    else {
        if (row.get("GrossVehicleWeight").intValue()>1000) {
            return PassengerVehicle.class;
        }
        else { return Motorcycle.class;
        }
    }
}

Entity Bean Inheritance Restrictions

The following restrictions apply to entity beans when using inheritance:

• The Home interfaces cannot inherit. The findByPrimaryKey method must be overloaded to have the correct return type, but this is not allowed. Because of this, inheritance is not applicable to the Home interfaces.

• The primary key of the subclass must be the same as that of the parent class.

The Application Server EJB 1.1 and 2.0 CMP Advanced Examples illustrate inheritance. For more information, see the OracleAS TopLink Examples at <ORACLE_HOME>\toplink\doc\examples.htm.