In the early stages of programming history, in the 1970s and 1980s, the principle aim was to write programs that were correct and robust.A program is considered correct if it does exactly what is said in the program specification. A program is considered robust if it can react appropriately to (user) errors and does not just crash immediately.

As programs grew in scope and complexity, more attention began to be paid to the possibilities of extensibility and re-usability, in order to avoid constantly having to re-invent the wheel.Extensibility is the facility to enhance an existing program by adding new functions, while still using it in the same context.

Re-usability, on the other hand, is when a program or part of a program is taken out of its own context and recycled in another context, that is, as part of another program that has different tasks.The Business Object Repository, the object-oriented view of the R/3 System, will be migrated to the Class Library by Rel5.0. Then classes, such as customer or invoice, will be available globally in the system for use by any application.

CREATE PUBLIC, the optional default supplement, allows unrestricted instantiation of objects in a class, that is, instances in a class can be created in any part of this program/class.CREATE PROTECTED only allows objects in a class to be instantiated in that class itself and in any of its subclasses.

CREATE PRIVATE only allows objects in a class to be instantiated in that class itself. This is then done using static methods (known as Factory Methods).

Example using the addition CREATE PRIVATE

Class lcl_manager wants to prevent several objects of this class existing at runtime. Only one instance is to be instantiated.Therefore the class defines the instantiation of objects as private and provides in its place the static method get_instance, which a potential client can use to get a reference to the sole object.

The CREATE OBJECT statement is extended by the introduction of inheritance and interfaces: you can enter the class of the instance to be created either statically, using the class name, or dynamically, using a variable containing the class name. Once the statement has been executed (successfully), a (runtime) instance of the class entered will have been created and the reference variable entered points to this instance.

There are two possible situations:

For a reference variable referring to a class, enter the name of a subclass (or of the class itself).
­ For a reference variable referring to an interface, enter the name of the class carrying out the implementation.

A check can be carried out in the static form “... TYPE …” to see if one of the two situations above has occurred. If it has not, a syntax error will occur.

In the dynamic form “...TYPE ().” the classname_string field provides the class name. A check can be carried out at runtime to ensure that the reference variable type is compatible with the class entered. If this is not the case, a runtime error occurs.

In the dynamic form, you can only enter the names of classes whose (instance)
constructor either has no parameters or only optional parameters.

If the line type of an internal table contains references variables in the component comp, their attributes can accessed in the following statements:

LOOP AT itab ... WHERE comp->attr ...
READ TABLE itab ... WITH [TABLE] KEY comp->attr ...
SORT itab BY comp->attr ...
DELETE itab WHERE comp->attr ...
MODIFY itab ... TRANSPORTING .. WHERE comp->attr ...

If an internal table has unstructured lines of the reference variable type, then the attributes of the object that the line points to can be addressed using TABLE_LINE->attr.

In the class carrying out the implementation, you can assign an alias name to an interface component using the ALIASES statement for the class itself and all its users.

This is however only an abbreviation of the long name. Even if an alias is assigned for an interface method, the method only needs to be implemented once as ~. Alias names are subject to the usual visibility rules.

The most important use for alias names is in nested interfaces. In the definition of a nested interface, the components of the component interfaces cannot be addressed directly, but only using their alias names.

Alias names can be used in classes to enable class-specific components that have been replaced by components from interfaces during the course of the development cycle to continue to be addressed by their old names. This means that the users of the class to not need to be adjusted in accordance with the new names.

Alias names cannot be used in the IMPLEMENTATION part of the class itself.

A subclass always co-inherits the supported interfaces from its superclass, but does have the options of implementing additional interfaces and redefining inherited interface methods.

If the subclass supports a compound interface, one of whose component interfaces is already implemented in the superclass, then the subclass does not need to do anything about the implementation of the component interface, but simply inherits its implementation (as long as there are no ABSTRACT constructs involved).

In this case it would only need to implement the additional methods of the compound interface, although it could also redefine methods from the component interface.

The principle that interface components are only present once in any one class or interface is still valid.

In the situation described above, it is therefore irrelevant, whether the subclass is supporting the interface method because it is implementing a compound interface, or because the superclass is implementing a component interface.

The unique ~ names of interface components ensure that interface components that are ‘inherited’ in a variety of ways can always be correctly identified and distinguished from one another.

Static events can be triggered in instance methods and in static methods.

Classes or their instances that want to receive a message if an event is triggered and react to this event define event handler methods

This class or its instances register themselves for one or more events at runtime.
Statement: SET HANDLER .
At runtime a class/instance can trigger a static event using the RAISE EVENT statement.

Static events, like attributes, only exist once per roll area. It is not the case that every subclass has its own copy of the static event.

All registrations for an event therefore refer to a single event, even if the event handler method registered is defined with reference to the inherited static event of a subclass.

Consequently, triggering a static event, be it in the defining class or in a subclass, activates all current handlers for this event, and not just those that are defined with reference to a specific class.



CRM Technical Architecture


  1. Hello... as a working mom and ABAPer...I really appreciate this kind of documents. As it gives a great insight. I am sure this will put me in a position where I can aim to the new OO generation. As I started with 2.2c is hard for me to "switch" into OO. But this information sure will put me in the right direction. THANKS!
    Lauris P. G.

  2. Very well written. Helped me recaping all the OO concepts :)

  3. Nice article..helped me to recap entire oo abap for my UCF exam@ WIPRO TECHNOLOGIES