Downcasts

Reference variables of the superclass can also refer to the subclass instances at runtime. You may copy this reference back to a reference variable of the subclass type.

To assign a superclass reference to a subclass reference, you must use the downcast assignment operator MOVE ... ?TO ... or its short form ?=. Otherwise, you get a message stating that it is not certain that all the components that can be accessed syntactically after the cast assignment are actually available in the instance. As a rule, the subclass contains more components than the superclass.

After assigning this type of reference back to a subclass reference to the implementing class, clients are no longer limited to inherited components. In the example shown in the figure, all the components of the LCL_TRUCK instance can be accessed again after the assignment using the GO_TRUCK2 reference.

Therefore, the view is either widened or not changed. This type of assignment of reference variables is known as downcast. There is a switch from a view of a few components to a view of many components. As the target variable can accept less dynamic types after the assignment, this assignment is also called a narrowing cast.

Specific Access After Downcast Assignments

Downcast assignments are used when you need to address specific components of instances and keep the references of these components in variables that are typed on the superclass. A user who is interested in the finer points of the instances of a subclass cannot use the superclass reference for this access because it allows access only to the shared components.

Exceptions Handling for Downcasts

In this example, a car rental company (LCL_RENTAL) has to determine the maximum capacity of its trucks, but it stores all types of vehicle references in an internal table LCL_VEHICLE. There may be a problem if there is no truck reference in the LO_VEHICLE superclass reference at runtime but the downcast assignment operator tries to copy the reference to the now invalid reference LO_TRUCK.

In contrast to the up-cast assignment, it is possible that the static type of the target variable (LO_TRUCK) is neither more general than nor the same as the dynamic type of the source variable (LO_VEHICLE), namely when LO_VEHICLE contains bus or sports car references. That is the reason why with this kind of cast, the runtime system checks before the assignment whether the current content of the source variable corresponds to the type requirements of the target variable. Otherwise, an exception that can be handled is triggered and the original value of the target variable remains the same.

You can identify this exception of the error class CX_SY_MOVE_CAST_ERROR using TRY-ENDTRY and the CATCH statement. Another way of preventing this runtime error is to use runtime type identification (RTTI) classes. You can use RTTI classes to determine the dynamic type at runtime and set a condition for the cast.

Usage of Class Hierarchies

As early as the modeling phase, you can identify a generalization and specialization relationship between certain classes. If such a relationship exists between certain classes, you can use inheritance to represent this in ABAP Objects.

For example, the semantics must be preserved when you redefine methods. Furthermore, inherited components must be used as intended in the superclass.

Misuse of Inheritance

In some cases, specialization relationships that do not allow for semantics to be retained need to be identified.

For example, the square class inherits from the rectangle class. If you try to define methods for the rectangle that change the width and height separately, these methods will not make sense when applied to the square. Even if the methods are redefined to make the lengths of the sides uniform, the semantics will be different.

For the same reason, that is, using inheritance only because some required functions are found in a superclass is also not appropriate.