In ABAP Objects, the constructor is not inherited like normal methods. Any class can define its own constructor that is fully independent from the definition of the constructor in its superclass. A subclass can even define a constructor if there is no constructor in the superclass.

However, when implementing the subclass constructor, it is mandatory to call the constructor of the immediate superclass. By doing so, it is ensured that the constructor of class is always executed, whether the created object is an instance of the class itself, or an instance of one of its subclasses.

Because of this enforced call of the superclass constructor, the subclass constructor generally adds parameters to the signature of the superclass constructor rather than completely changing it.

In this context, the concept of overloading is of relevance. With overloading, a method can have several definitions with different signatures and different implementations. The concept of overloading is not supported in ABAP Objects. The usual work-around is one signature with different sets of optional parameters.

In contrast to instance constructors, the runtime environment automatically ensures that the static constructors of all its superclasses have already been executed before the static constructor in a particular class is executed in the runtime system.

Rules for Calling the Constructor

If a subclass has not changed its instance constructor, the constructor is adopted from the superclass. The implementation is also inherited from the superclass.

Inheritance and Visibility

Inheritance provides an extension of the visibility concept through protected components (PROTECTED SECTION). The visibility of protected components lies between public and private components. Protected components are visible to all subclasses and the class itself.

When defining local classes in ABAP Objects, follow the syntactical sequence of the PUBLIC SECTION, the PROTECTED SECTION, and the PRIVATE SECTION.

Visibility Section – Protected Versus Private

The components inherited from the superclass  may not be visible in the subclass. A subclass can receive private components from its superclass, which cannot be addressed in the syntax of the subclass. Private components of superclasses can only be addressed indirectly using public or protected methods from the superclass, which in turn, can access the private attributes. These restrictions are necessary to ensure that centralized maintenance is possible.

In this example, it is possible to access the protected constant C_POS_1 in superclass LCL_VEHICLE directly from its subclass LCL_BUS. On the other hand, the only way to access the private MV_MAKE and MV_MODEL attributes from the subclasses of LCL_VEHICLE is to call methods of LCL_VEHICLE. These methods have to be public or protected.

Using the PRIVATE SECTION, you can change superclasses without the need to know the subclasses. As long as the changes you make do not affect the semantics, you do not need to adapt the subclasses. This is because they only indirectly access the private components from the superclass.

Inheritance and Static Components

The following is a summary of static components and inheritance:

• A class that defines a public or protected static attribute shares this attribute with all its subclasses.
• Static methods cannot be redefined.
• The static constructor of a superclass is executed when the superclass or one of its subclasses is accessed for the first time.
• A subclass can always have a static constructor, irrespective of the superclass.
• If a subclass and its superclass both have a static constructor, then both constructors are executed when we access the subclass for the first time. If access to the superclass and subclass static constructor occurs at the same time, the superclass static constructor will execute first, immediately followed by the subclass static constructor.