Generic Access to Objects

A typical use for up-cast assignments is to prepare for generic access. A user who is not interested in the finer points of the instances of the subclasses but simply needs to address the shared components can use a superclass reference for this access.

In the example, a travel agency LCL_RENTAL needs to manage all imaginable kinds of vehicles in one list. To manage all these vehicles in one list, create an internal table, and assign it with an appropriate type for the references to the vehicle instances. The car rental company also needs to be able to calculate the required amount of fuel for all its vehicles. In this case, the DISPLAY_ATTRIBUTES method, which is defined in the superclass LCL_VEHICLE must be redefined in all subclasses.

Row Type of the Internal Table in the Application – Example

When objects of different classes (LCL_BUS, LCL_TRUCK and LCL_CAR) are specified as type superclass references (LCL_VEHICLE), these objects can be stored in an internal table. The shared components of the subclass objects can then be accessed uniformly. For this example, you need the method ADD_VEHICLE to copy the references to the vehicle types into the internal table. The import parameter of this method is already typed as the reference to the superclass.

Up-Cast and Generic Access in the Application – Example

In this example, the up-cast assignment occurs when the vehicle reference is transferred to the formal parameter of ADD_VEHICLE method. The shared component is generically accessed within the loop around the internal table containing all of the vehicle references. The DISPLAY_ATTRIBUTES method was inherited from the LCL_VEHICLE superclass and may have been redefined.

Polymorphism

The implementation to be executed when DISPLAY_ATTRIBUTES is called depends on which object the superclass reference LO_VEHICLE refers to. The dynamic type (not the static type) of the reference variable is used to search for the implementation of a method. Therefore, when lo_vehicle->display_attributes is called, the implementation is not executed from LCL_VEHICLE (the static type of LO_VEHICLE) because the method was redefined in all vehicle classes.

When an instance receives a message to execute a particular method, the method that implemented the class of this instance is executed. If the class has not been redefined in the method, the implementation from the superclass is executed.

Characteristics of Polymorphism

When objects from different classes react differently to the same method calls, this is known as polymorphism. The possibility of polymorphism is one of the main strengths of inheritance. A client can handle different classes uniformly, irrespective of their implementation. The runtime system searches for the right implementation of a method on behalf of the client.

Polymorphism can be used to write programs that are highly generic, that is, they do not need to be changed significantly if use cases are added. For instance, polymorphism may make it easy to add motorbikes to this example. You simply need to define a new subclass of LCL_VEHICLE, which you can call LCL_MOTORBIKE. You would also have to redefine the inherited method DISPLAY_ATTRIBUTES. Without needing any more changes, your vehicle management system can then work with motorbikes, as well as, calculate the required fuel levels for them.

Generic Calls in the Procedural Programming Model

Using dynamic function module calls, you can program generically in ABAP, even without an object-oriented programming model. When you compare the dynamic function module call with polymorphism through inheritance, the source code is less self-explanatory and is more susceptible to errors in dynamic function module call. For example, the syntax check can only check whether the function module is called correctly or not. The syntax check cannot check whether the internal table contains a valid function module name for each vehicle or not.