Inheritance is a relationship in which one class (the subclass) inherits all the main characteristics of another class (the superclass). The subclass can also add new components (attributes, methods, and so on) and replace inherited methods with its own implementations.
Inheritance is an implementation relationship that emphasizes similarities between classes. In the example above, the similarities between the passenger plane and cargo plane classes are extracted to the airplane superclass. This means that common components are only defined/implemented in the superclass and are automatically present in the subclasses.
The inheritance relationship is often described as an “is-a” relationship: a passenger plan is an airplane.Inheritance should be used to implement generalization and specialization relationships. A superclass is a generalization of its subclasses. The subclass in turn is a specialization of its superclasses.
The situation in which a class, for example lcl_8, inherits from two classes (lcl_6 and lcl_7) simultaneously, is known as multiple inheritance. This is not realized in ABAP Objects. ABAP Objects only has single inheritance.However, you can simulate multiple inheritance in ABAP Objects using interfaces (see the section on interfaces).
Single inheritance does not mean that the inheritance tree only has one level. On the contrary, the direct superclass of one class can in turn be the subclass of a further superclass. In other words: the inheritance tree can have any number of levels, so that a class can inherit from several superclasses, as long as it only has one direct superclass.
Inheritance is a “one-sided relationship”: subclasses know their direct superclasses, but (super)classes do not know their subclasses.
Normally the only other entry required for subclasses is what has changed in relation to the direct superclass. Only additions are permitted in ABAP Objects, that is, in a subclass you can “never take something away from a superclass”. All components from the superclass are automatically present in the subclass.
If inheritance is used properly, it provides a significantly better structure, as common components only need to be stored once centrally (in the superclass) and are then automatically available to subclasses. Subclasses also profit immediately from changes (although the changes can also render them invalid!).
Inheritance provides very strong links between the superclass and the subclass.
The subclass must possess detailed knowledge of the implementation of the superclass, particularly for redefinition, but also in order to use inherited components.
Even if, technically, the superclass does not know its subclasses, the subclass often makes additional requirements of the superclass, for example, because a subclass needs certain protected components or because implementation details in the superclass need to be changed in the subclass in order to redefine methods.
The basic reason is that the developer of a (super)class cannot normally predict all the requirements that subclasses will later need to make of the superclass.
Inheritance provides an extension of the visibility concept: there are protected components. The visibility of these components lies between that of the public components (visible to all users, all subclasses, and the class itself), and private (visible only to the class itself). Protected components are visible to and can be used by all subclasses and the class itself.
Subclasses cannot access the private components (particularly attributes) of the superclass. Private components are genuinely private. This is particularly important if a (super)class needs to make local enhancements to handle errors: it can use private components to do this without knowing or invalidating subclasses.
In ABAP Objects, you must keep to the section sequence PUBLIC, PROTECTED, PRIVATE.
The constructor of the superclass must be called within the constructor of the subclass. The reason for this is the special task of the constructor: to ensure that objects are initialized correctly. Only the class itself, however, can initialize its own (private) components correctly; this task cannot be carried out by the subclass. Therefore it is essential that all (instance) constructors are called in an inheritance hierarchy (in the correct sequence).
For static constructors, unlike instance constructors, the static constructor in the superclass is called automatically, that is, the runtime system automatically ensures that, before the static constructor in a particular class is executed, the static constructors of all its superclasses have already been executed.
You must also consider the model described for instance constructors when using CREATE OBJECT. In this model, the constructor of the immediate superclass must be called before the non-inherited instance attributes can be initialized.
There are basically two methods of creating an instance in a class using
CREATE OBJECT:
1. The instance constructor for that class has been defined (and implemented).
In this case, when you are using CREATE OBJECT, the parameters have to be filled according to the constructor interface, that is, optional parameters may, and non-optional parameters must be filled with actual parameters. If the constructor does not have any (formal) parameters, no parameters may or can be filled.
2. The instance constructor for that class has not been defined.
In this case, you must search the inheritance hierarchy for the next highest superclass in which the instance constructor has been defined and implemented. Then, when you are using CREATE OBJECT, the parameters of that class must be filled (similarly to the first method above).
If there is no superclass with a defined instance constructor, then no parameters may or can be filled.
If no instance constructor has been defined for a class, then a default constructor, which is implicitly always present is used. This default constructor calls the constructor from the immediate superclass.
In ABAP Objects, you can not only add new components, but also provide inherited methods with new implementations. This is known as redefinition. You can only redefine (public and protected) instance methods, other components (static methods, attributes and so on) cannot be redefined. Furthermore, implementation is restricted to (re-)implementation of an inherited method; you cannot change method parameters (signature change).
You also cannot redefine a class’s (instance) constructor.
In UML, the redefinition of a method is represented by listing the method again in the subclass. Methods (and all other components) that are inherited but not redefined are not listed in the subclass, as their presence there is clear from the specialization relationship.
You should not confuse redefinition with “overlaying”. This describes the ability of a class to have methods with the same name but a different signature (number and type of parameters). This option is not available in ABAP Objects.
The REDEFINITION statement for the inherited method must be in the same SECTION as the definition of the original method. (It can therefore not be in the PRIVATE SECTION, since a class’s private methods are not visible and therefore not redefinable in subclasses!)
If you redefine a method, you do not need to enter its interface again in the subclass, but only the name of the method. The reason for this is that ABAP Objects does not support overlaying
To implement a redefined method in a subclass, you often need to call the method of the same name in the immediate superclass. In ABAP Objects you can call the method from the superclass using the pseudo-reference super: CALL METHOD super->method_name.The pseudo-reference super can only be used in redefined methods.
RELATED LINKS
OOPS ABAP 8
CRM Middle ware Data Load and Monitoring
Inheritance is an implementation relationship that emphasizes similarities between classes. In the example above, the similarities between the passenger plane and cargo plane classes are extracted to the airplane superclass. This means that common components are only defined/implemented in the superclass and are automatically present in the subclasses.
The inheritance relationship is often described as an “is-a” relationship: a passenger plan is an airplane.Inheritance should be used to implement generalization and specialization relationships. A superclass is a generalization of its subclasses. The subclass in turn is a specialization of its superclasses.
The situation in which a class, for example lcl_8, inherits from two classes (lcl_6 and lcl_7) simultaneously, is known as multiple inheritance. This is not realized in ABAP Objects. ABAP Objects only has single inheritance.However, you can simulate multiple inheritance in ABAP Objects using interfaces (see the section on interfaces).
Single inheritance does not mean that the inheritance tree only has one level. On the contrary, the direct superclass of one class can in turn be the subclass of a further superclass. In other words: the inheritance tree can have any number of levels, so that a class can inherit from several superclasses, as long as it only has one direct superclass.
Inheritance is a “one-sided relationship”: subclasses know their direct superclasses, but (super)classes do not know their subclasses.
Normally the only other entry required for subclasses is what has changed in relation to the direct superclass. Only additions are permitted in ABAP Objects, that is, in a subclass you can “never take something away from a superclass”. All components from the superclass are automatically present in the subclass.
If inheritance is used properly, it provides a significantly better structure, as common components only need to be stored once centrally (in the superclass) and are then automatically available to subclasses. Subclasses also profit immediately from changes (although the changes can also render them invalid!).
Inheritance provides very strong links between the superclass and the subclass.
The subclass must possess detailed knowledge of the implementation of the superclass, particularly for redefinition, but also in order to use inherited components.
Even if, technically, the superclass does not know its subclasses, the subclass often makes additional requirements of the superclass, for example, because a subclass needs certain protected components or because implementation details in the superclass need to be changed in the subclass in order to redefine methods.
The basic reason is that the developer of a (super)class cannot normally predict all the requirements that subclasses will later need to make of the superclass.
Inheritance provides an extension of the visibility concept: there are protected components. The visibility of these components lies between that of the public components (visible to all users, all subclasses, and the class itself), and private (visible only to the class itself). Protected components are visible to and can be used by all subclasses and the class itself.
Subclasses cannot access the private components (particularly attributes) of the superclass. Private components are genuinely private. This is particularly important if a (super)class needs to make local enhancements to handle errors: it can use private components to do this without knowing or invalidating subclasses.
In ABAP Objects, you must keep to the section sequence PUBLIC, PROTECTED, PRIVATE.
The constructor of the superclass must be called within the constructor of the subclass. The reason for this is the special task of the constructor: to ensure that objects are initialized correctly. Only the class itself, however, can initialize its own (private) components correctly; this task cannot be carried out by the subclass. Therefore it is essential that all (instance) constructors are called in an inheritance hierarchy (in the correct sequence).
For static constructors, unlike instance constructors, the static constructor in the superclass is called automatically, that is, the runtime system automatically ensures that, before the static constructor in a particular class is executed, the static constructors of all its superclasses have already been executed.
You must also consider the model described for instance constructors when using CREATE OBJECT. In this model, the constructor of the immediate superclass must be called before the non-inherited instance attributes can be initialized.
There are basically two methods of creating an instance in a class using
CREATE OBJECT:
1. The instance constructor for that class has been defined (and implemented).
In this case, when you are using CREATE OBJECT, the parameters have to be filled according to the constructor interface, that is, optional parameters may, and non-optional parameters must be filled with actual parameters. If the constructor does not have any (formal) parameters, no parameters may or can be filled.
2. The instance constructor for that class has not been defined.
In this case, you must search the inheritance hierarchy for the next highest superclass in which the instance constructor has been defined and implemented. Then, when you are using CREATE OBJECT, the parameters of that class must be filled (similarly to the first method above).
If there is no superclass with a defined instance constructor, then no parameters may or can be filled.
If no instance constructor has been defined for a class, then a default constructor, which is implicitly always present is used. This default constructor calls the constructor from the immediate superclass.
In ABAP Objects, you can not only add new components, but also provide inherited methods with new implementations. This is known as redefinition. You can only redefine (public and protected) instance methods, other components (static methods, attributes and so on) cannot be redefined. Furthermore, implementation is restricted to (re-)implementation of an inherited method; you cannot change method parameters (signature change).
You also cannot redefine a class’s (instance) constructor.
In UML, the redefinition of a method is represented by listing the method again in the subclass. Methods (and all other components) that are inherited but not redefined are not listed in the subclass, as their presence there is clear from the specialization relationship.
You should not confuse redefinition with “overlaying”. This describes the ability of a class to have methods with the same name but a different signature (number and type of parameters). This option is not available in ABAP Objects.
The REDEFINITION statement for the inherited method must be in the same SECTION as the definition of the original method. (It can therefore not be in the PRIVATE SECTION, since a class’s private methods are not visible and therefore not redefinable in subclasses!)
If you redefine a method, you do not need to enter its interface again in the subclass, but only the name of the method. The reason for this is that ABAP Objects does not support overlaying
To implement a redefined method in a subclass, you often need to call the method of the same name in the immediate superclass. In ABAP Objects you can call the method from the superclass using the pseudo-reference super: CALL METHOD super->method_name.The pseudo-reference super can only be used in redefined methods.
RELATED LINKS
OOPS ABAP 8
CRM Middle ware Data Load and Monitoring
No comments :
Post a Comment