Inheritance of Persistent Classes - ABAP Keyword Documentation

ABAP - Keyword Documentation → ABAP - Reference → Processing External Data → ABAP Database Accesses → Object Services → Persistence Service →

Inheritance of Persistent Classes

Persistent classes can have subclasses. These subclasses are also persistent classes, in that they inherit the persistence mapping of the superclass to the database table or tables. The persistence mapping of the superclass is defined in the subclass. If not, the general polymorphic principle of inheritance, in which the consumer handles subclasses in the same way as superclasses, is violated.

The mapping information and attributes of all superclasses are included in the class agents of a persistent subclass. There are two different methods for passing on mappings.

Vertical mapping

In the subclass, the persistent attributes that were defined in the subclass are mapped to separate tables, database views, or structures. The general rule for multiple table mapping applies: The keys for the additional tables, database views, or structures must be the same as the keys for the superclass tables, database views, or structures. The key fields are therefore mapped in the superclass and the subclass. Thus additional attributes and their associated GET and SET methods are added to the subclass, without affecting the attributes and methods of the superclass. In the superclass, all persistent attributes must be mapped.

A special case of vertical mapping exists when the persistent attributes that were additionally defined in the subclass are mapped to the same tables, database views, or structures as the superclass attributes. To find out the class to which a table entry belongs, a special field of the type OS_GUID must exist in one of the tables, database views, or structures and be used as a type identifier.

Horizontal mapping

If a persistent superclass is abstract, persistent attributes can be defined there without using concrete mappings. In every direct subclass, a mapping must be defined for the persistent attributes of the superclass. The subclasses can be mapped to different tables, database views, or structures. The system does not check whether the subclasses are mapped to different tables or structures.

Caution

The class agents of persistent classes that are in an inheritance relationship are not in a corresponding inheritance relationship. The same principle applies that a class agent only manages the objects of the corresponding classes and the subclass objects. As a result, private attributes of non-final persistent classes are not completely protected from reads or writes. Information that is to be protected must not be stored in private attributes of non-final persistent classes.

Polymorphism in the Class Agent Methods

The methods DDELETE_PERSISTENT, REFRESH_PERSISTENT, and RELEASE of the interface IF_OS_FACTORY of the class agent behave polymorphically; this means that, for a specified managed object, these methods can also be called in the class agent of a (non-abstract) superclass of this object. At runtime, the passed reference can be used to define the type of the managed object and call the relevant class agent of the subclass.

If an additional type field (type identifier) exists in one of the tables, database views, or structures that is mapped to the root class of the inheritance hierarchy, the methods GET_PERSISTENT, DELETE_PERSISTENT plus GET_PERSISTENT_BY_KEY and GET_PERSISTENT_BY_OID of the interface IF_OS_CA_PERSISTENCY of the class agent behave polymorphically. This means that the agent of a (non-abstract) persistent class can also be used to use the key to read (business key or GUID) or delete (business key) a persistent object that belongs to a persistent subclass of the classes managed by this class agent. This is done by delegation to the class agent of the subclass, which can be determined at runtime using the information in the type identifier.

Specifying an additional type identifier ensures that the (business) key is unique in the entire inheritance hierarchy. It is therefore not possible to create a managed object with the same key as a managed object of another subclass, superclass, or the latter’s subclasses.