Objects from different classes (lcl_cargo_airplane and lcl_passenger_airplane in the above example ) can be stored in an internal table consisting of references to the superclass (lcl_airplane in the above example, and then processed identically (polymorphically) (see next slide).

What coding is actually executed when estimate_fuel_consumption is called depends on the dynamic type of the plane reference variable, that is, it depends on which object from which (sub)class plane points to.

You can use polymorphism to write programs that are generic to a high degree and that do not even need to be changed if use cases are added. In the simple example above, this means that, should a further subclass be added, for example, for airplanes that fly in space, the above coding would not need to be changed.

Using polymorphism makes generic programming easier. Instead of implementing a CASE or IF statement, you can have one access or call, which improves readability and does not need to be changed if you extend the program by adding further subclasses.


You cannot instantiate objects in an abstract class. This does not, however, mean that references to such classes are meaningless. On the contrary, they are very useful, since they can (and must) refer to instances in subclasses of the abstract class during runtime. The CREATE-OBJECT statement is extended in this context. You can enter the class of the instance to be created explicitly:

Abstract classes are normally used as an incomplete blueprint for concrete (that is, non-abstract) subclasses, in order to define a uniform interface, for example.

Abstract instance methods are used to specify particular interfaces for subclasses, without having to immediately provide implementation for them. Abstract methods need to be redefined and thereby implemented in the subclass (here you also need to include the corresponding redefinition statement in the DEFINITION part of the subclass).

Classes with at least one abstract method are themselves abstract

Static methods and constructors cannot be abstract (they cannot be redefined).

A final class cannot have subclasses, and can protect itself in this way against (uncontrolled) specialization.

A final method in a class cannot be redefined in a subclass, and can protect itself in this way against (uncontrolled) redefinition.

Some characteristics:
­ A final class implicitly only contains final methods. You cannot enter FINAL explicitly for these methods in this case.

­ Methods cannot be both final and abstract.
­ Classes, on the other hand, can usefully be both abstract and final: only static components can be used there.

In ABAP Objects, all static components in an inheritance relationship are shared.

For attributes this means that each static attribute only exists once per roll area. In this way a class that defines a public or protected static attribute shares this attribute with all its subclasses. The significant point here is that subclasses do not each receive their own copy of the static attribute.

Shared static methods cannot be redefined in subclasses. However, you can call inherited (public or protected) static methods using subclasses.

Adding private components is never a problem. Adding public or protected components to a class can however invalidate that class’s subclasses, if they already contain components with the same name. When you add that component, you get the syntax error message that that component has already been declared.

Using inheritance instead of attributes, or a misunderstanding of inheritance as an “is-one” relationship often leads to the following kind of design: the superclass “car” has the subclasses “red car”, “green car”, and so on. These subclasses all have an identical structure and identical behavior.

As an instance cannot change its class, in circumstances like the following, you should not use inheritance directly, but use additional attributes to differentiate between cases (see appendix):

The class “employee” has the subclasses “full-time employee” and “part-time employee”. What happens when a part-time employee becomes a full-time employee? A new full-time-employee object would have to instantiated and all the information copied from the part-time-employee object. However, users who still have a reference to the part-time-employee instance would then be working with a part-time-employee object that logically does not exist anymore!

The use of inheritance does not always correspond to expectations in the real world: for example, if the class ‘square’ inherits from the class ‘rectangle’, the latter will have two separate methods for changing length and width, although the sides of the square actually need to be changed by the same measurement.



CRM Middle ware Data Load and Monitoring

No comments :

Post a Comment