ABAP Objects Overview

ABAP Objects - Overview
Table of Contents
Object Orientation, 1
Definition of Classes and Interfaces, 2
Classes, 3
.. Components of Classes, 3.1
.... Visibility Sections in Classes, 3.1.1
.... Attributes, 3.1.2
.... Methods, 3.1.3
...... Interface Parameters in Methods, 3.1.3.1
...... The C Destructor, 3.1.3.2
...... Kernel Methods, 3.1.3.3
.... Constructors, 3.1.4
...... Visibility of Instance Constructors, 3.1.4.1
.... Events, 3.1.5
.... Data Types and Constants, 3.1.6
Inheritance, 4
.. Redefining Methods, 4.1
.. Abstract and Final Methods and Classes, 4.2
.. Inheritance and Polymorphism, 4.3
.. Inheritance and Interfaces, 4.4
.. Inheritance and Visibility, 4.5
.. Inheritance and the Component Namespace, 4.6
.. Inheritance and Static Components, 4.7
.. Inheritance and Constructors, 4.8
.. Inheritance and Instantiation, 4.9
.. Inheritance and Events, 4.10
Interfaces, 5
.. Nesting Interfaces, 5.1
Events, 6
Friends - Friendship Between Classes, 7
Objects, 8
.. Object References, 8.1
.. Accessing Class Components, 8.2
.. Object References in Internal Tables, 8.3
.. Weak References, 8.4
Statements in ABAP Objects, 9
.. Statements for Defining Classes and Interfaces, 9.1
.. Statements for implementing methods, 9.2
.. Statements in Class and Interface Pools, 9.3
.. ABAP Objects - Keywords, 9.4
.. Replacements for Obsolete Language Constructs in ABAP Objects, 9.5
Examples for ABAP Objects, 10
.. ABAP Objects, Overview, 10.1
.. ABAP Objects, Classes, 10.2
.. ABAP Objects, Inheritance, 10.3
.. ABAP Objects, Interfaces, 10.4
.. ABAP Objects, Events, 10.5
.. ABAP Objects, OO Transaction, 10.6

ABAP Objects is the object-oriented extension of the ABAP language.
ABAP Objects adds a complete set of language elements to ABAP that allow object-oriented programming. This
object-oriented extension of ABAP builds on the previous range of languages, and is fully compatible with them.
Page 1 of 51 ABAP Keyword Documentation
17/3/2014 saphtmlp://htmlviewer.sap.com/6Aa5YHcp7kEhmJX{mY9oa0/HTML000349.htm
ABAP Objects can be used in existing programs, and the statements that can be used in ABAP Objects
correspond to practically all of the remaining SAP language scope. However, specific obsolete language elements
are not permitted in conjunction with ABAP objects due to a clean up of the ABAP language.
ABAP Objects supports:

Classes
Interfaces
Objects
Object References
Inheritance
Note
Package SABAP_DEMOS_CAR_RENTAL contains a complete sample application written in ABAP Objects. Its
presentation layer is implemented using a Web Dynpro or screen. The Web Dynpro calls interface methods that
are implemented in a class and that, in turn, access classes that implement database accesses.
1 Object Orientation
Object orientation (or, more correctly, object-oriented programming) is a problem-solving method that represents
the real world in a series of software objects.
Object-oriented programming is based on a progamming model in which data and functions are unified in objects.
The remaining language scope of ABAP mainly supports procedural programming, where the data is stored at
other places than the objects and where programs that are modularized by procedures access this data.
This document defines a few general terms that are widely used in object orientation and in ABAP Objects.
Objects
Objects represent abstract or concrete objects of the real world. An object is a section of program code that
has data (called attributes) and provides services called methods (sometimes also known as operations or
functions). Methods typically work with private data in the object (attributes, also known as the object state),
that are only visible within the object. This guarantees the internal consistency of the object, since the data
is only changed by the methods, not by the user. This ensures that the object is consistent in itself.
Classes
Classes are program code that describes objects. Technically, an object is an instance of a class. In theory,
you can create an infinite number of objects from a single class definition. Each instance of a class (object)
has its own values for its attributes.
Object References
In a program, you identify and address objects using a unique object reference. They allow you to access
the attributes and methods of an object.
In object-oriented programming, objects usually have the following characteristics:
Encapsulation
Objects restrict the external visibility of their resources (attributes and methods). Each object has an
interface that determines how other objects or applications can use it. The implementation of the object is
encapsulated (not visible outside the class).
Polymorphism
Methods with the same name can behave differently in different classes. In object-oriented programming,
you can use interfaces to address methods with the same name in different objects. The form of address
always remains the same, but the actual method implementation is class-specific, and can be different in
each class.
Inheritance
You can derive a class from another class. A derived class (subclass) inherits the data and methods of its
superclass. You can add new methods to a subclass, or redefine existing methods. Redefined methods
have the same name and interface as the original method. Their classes are therefore polymorphous, too.
Benefits of Object Orientation
Object orientation has the following advantages:
Complex software systems become easier to understand, since an object-oriented architecture resembles
reality more closely than other programming techniques.
Changes in object-oriented systems should be possible locally (at class level), without further changes
being necessary in other parts of the system. This reduces the amount of maintenance required.
Polymorphism and inheritance enable many individual components to be reused.
Object-oriented systems require fewer revisions and less maintenance, because the majority of problems
can be discovered and corrected in the design and development phases.
Achieving these goals requires:
Object-oriented programming languages

Object-oriented programming techniques do not necessarily require object-oriented programming
languages. However, they do depend on the implementation of object-oriented constructions in the system
kernel.
Object-oriented tools

Object-oriented tools help you create object-oriented programs in object-oriented languages. They allow
you to store and visualize your program objects and the relationship between them.
Object-oriented modeling

Object-oriented modeling of a software system is the most important, most time consuming, and most
difficult task required to achieve the above goals. Object-oriented design encompasses more than just
object-oriented programming, and offers logical advantages that are independent of the eventual
implementation.

2 Definition of Classes and Interfaces
Classes and interfaces in ABAP Objects can be declared either globally or locally.
You define global classes and interfaces with the Class Builder in ABAP Workbench. They are stored
centrally in the class library in the repository. From a technical perspective, global classes and interfaces
are defined in class pools or interface pools. All ABAP programs in an AS ABAP can access these global
classes and interfaces. Access is managed by the package check. Global classes and interfaces are stored
in a namespace along with the data types of ABAP Dictionary.
You can define local classes and interfaces in all programs except interface pools and type groups. They
can be used statically only in the defining program. Dynamic access from other programs is possible but
not advisable. When you use a class in an ABAP program, the system first searches for a local class with
the specified name. If it does not find one, it then looks for a global class. Otherwise, there is no difference
between using global and local classes or interfaces.
If you are defining a local class that is only used in a single program, it is usually sufficient to define the outwardly
visible components so that it fits into that program. Conversely, each global class is available throughout the
system, which means that its public interface can only be specified with reference to data types that are
themselves visible throughout the system.
The syntax for defining classes and interfaces is essentially the same for local and global classes and interfaces.
The only difference is in the PUBLIC addition, which makes a distinction between the global classes and interfaces
and local declarations.
Global classes and interfaces can be edited in the Class Builder, either in form-based or source-code based mode.
In form-based mode, the Class Builder generates the relevant source code that can be accessed directly in
source-code based mode.
Defining Classes
Classes consist of ABAP source code, enclosed in the ABAP statements CLASS ... ENDCLASS. A complete class
definition consists of a declaration part and, if required, an implementation part.
The declaration part of a class named class consists of a statement block:

CLASS class DEFINITION.
...
ENDCLASS.
It contains the declaration for all components (attributes, methods, events) of the class. All the components of a
class must be assigned explicitly to a visibility section (PUBLIC SECTION, PROTECTED SECTION, PRIVATE
SECTION), which defines from where each component can be accessed. When you define local classes, the
declaration part belongs to the global program data. You should therefore place it at the beginning of the program.
If you declare methods in the declaration part of a class, you must also write an implementation part for it. This
consists of a further statement block:

CLASS class IMPLEMENTATION.
...
ENDCLASS.
The implementation part of a class contains the implementation of all methods of the class. Methods are
procedures, that is, processing blocks of an ABAP program. The position of the implementation part in the source
code is thus unimportant. For clarity, however, you should either put all the implementation parts of local classes at
the end of the program, or directly after the relevant definition part. If you do the latter, note that you must then
assign subsequent non-declarative statements explicitly to a processing block such as START-OF-SELECTION, so
that they can be accessed.
Defining Interfaces
The definition of an intf interface is enclosed in the statements:

INTERFACE intf.
...
ENDINTERFACE.
The The definition contains the declaration for all components (attributes, methods, events) of the interface. In
interfaces, you can define the same components as in classes. You cannot assign the components of an interface
explicitly to a visibility section, because interface components always extend the public area of a class when they
are implemented in it. Interfaces do not have an implementation part, since their methods are implemented in the
class that implements the interface.
3 Classes
The type of an object is known as its class. A class is an abstract representation, or, metaphorically speaking, a
set of instructions for building objects. So that you can describe the properties of objects, classes contain
components, which define the state and behavior of objects.
Global and Local Classes
You can define classes globally in the class library in the repository or locally in an ABAP program.
Global classes are coded in a special ABAP program, a Class-Pool, whereas local classes can be coded in almost
every ABAP program. Global classes are visible in all ABAP programs. The usablity depends on the package
check. Local classes can only be used statically in their own program. Dynamic accesses are also possible across
program limits but it is not recommended. When a global class is used for the first time, the class pool is loaded
into the internal session of the user. The local classes of a class pool can be used by the pool's global classes.
Except for the storage type and the visibility, there are hardly any conceptual differences between global and local
classes. One of the few differences is that in the public interface of a global class only references to public types
are possible. These types are subdivided into global and local friends.
In principle, it also does not make any difference if you call a method of a local or global class. This is the reason
why classes that are used by several programs are exclusively created in the class library. You should avoid, if
possible, to reuse local classes using include programs.
3.1 Components of Classes
The content of a class is composed of components. The components define the attributes of objects of a class.
Each component is declared in the definition of the class in one of the four visibility sections that the interfaces
define externally. Within a class, all its components are visible. All components are in the same namespace, which
means that the names of all components in a class must be different.
The individual components are:

Attributes
Methods
Events
Types and constants
SAP makes a distinction between components of this type that are available on an instance-dependent basis for
every object, and instance-independent components that are only available once in a class. The instance-
dependent components are called instance components; the instance-independent components are known as
static components.
In ABAP objects, classes can define the components listed above. Since all components that can be declared in
classes can also be declared in interfaces, this description also applies to interfaces.
The components of classes can be accessed internally, and depending on the visibility, also from outside the
class. If they are accessed externally, component selectors must be used for addressing.
3.1.1 Visibility Sections in Classes
The declaration section of a class can be split into up to four different visibility sections.
These sections define the external visibility of the class components and therefore the interfaces of the class for all
users allowed by the package concept. Each component of a class must be explicitly assigned to one of the
visibility sections. Only the friends of a class ignore the associated restrictions.
Public visibility section

All components declared in the public visibility section defined with PUBLIC SECTION are accessible to all
users as well as in the methods of all inheritors and the class itself. The public components of the class
form the interface between the class and its users.
Protected visibility section

All components declared in the protected visibility section defined with PROTECTED SECTION are accessible
in the methods of all inheritors and in the class itself. Protected components form a special interface
between a class and its subclasses.
Private visibility section

All components declared in the private visibility section defined with PRIVATE SECTION are only accessible
in the class itself, and are also not visible to the inheritors. The private components therefore do not form an
interface to the users of the class.
The following table summarizes the visibilities of a class:

Note
A subclass can generally never access the protected components of a subclass from a different branch in the
inheritance hierarchy, even if they are inherited from a common superclass. This rule can only be lifted by a
friendship.
Encapsulation
The three visibility sections form the basis for the important feature of encapsulation in ABAP Objects. When
declaring a class, you should ensure you declare the minimum possible number of components in the public
section and create these public components carefully. The public components of global classes may not be
changed once you have released the class.
Programming Guideline
Exploit the benefits of encapsulation
Note
The class is the smallest encapsulation unit in ABAP Objects. A method can therefore use all components of all
instances of the same class, except for the components of its own class. An exception to this rule are subclasses
that cannot access the private components of superclasses, if they are not their friends.
Example
In method m1 of class c1, reference variables of static type c1 can be used to access the protected attribute a11
and the private attribute a12 of any objects of c1. In method m2 of subclass c2, a reference variable of static type
c2 can similarly be used to access the protected attribute a11. Access to the attribute using a reference variable of
static typec1 is not permitted, as it would otherwise also be possible to change an attribute of an object of the
superclass or another subclass. It is not possible to access the private attribute of the superclass with either
reference variable.
CLASS c1 DEFINITION.
PUBLIC SECTION.
METHODS m1.
PROTECTED SECTION.
DATA a11 TYPE i.
PRIVATE SECTION.
DATA a12 TYPE i.
Visible for PUBLIC SECTION PROTECTED SECTION PRIVATE SECTION
Same class and its friends X X X
Any subclasses X X -
Any repository objects X - -
ENDCLASS.

CLASS c1 IMPLEMENTATION.
METHOD m1.

DATA lref1 TYPE REF TO c1.

lref1->a11 = 0. "OK

lref1->a12 = 0. "OK

ENDMETHOD.
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM c1.
PUBLIC SECTION.
METHODS m2.
ENDCLASS.

METHOD m2.

DATA: lref1 TYPE REF TO c1,
lref2 TYPE REF TO c2.

lref1->a11 = 0. "Syntax warning, access to a11 not permitted

lref2->a11 = 0. "OK

"lref1->a12 = 0. "Syntax error, access to a11 not permitted

"lref2->a12 = 0. "Syntax error, a12 not visible

ENDMETHOD.
ENDCLASS.
3.1.2 Attributes
Attributes are data objects of any ABAP data type that are internal to a class. The content of the attributes
specifies the status of the object. You can also define reference variables, which you can then use to create and
address objects. This allows objects to be accessed within classes.
Attributes are defined in the declaration part of a class. Public attributes are completely visible from outside the
class and are therefore part of the interface between objects and their users. To encapsulate the status of the
object, you need to use protected, package-visible, or private attributes. You can also restrict the changeability of
non-private attributes using the READ-ONLY addition during the declaration.
Instance Attributes
The content of instance attributes forms the instance-dependent status of the object. Instance attributes are
declared using the DATA statement. You cannot use the COMMON PART addition in classes.
Static Attributes
The content of static attributes forms the instance-independent status of the object, which is valid for all instances
of the class. Static attributes are available once for each class. They are declared using the CLASS-DATA statement
and are retained throughout the entire runtime. All the objects within a class can access its static attributes.
Changes to a static attribute in an object are visible to all other objects within that class.
Data Types of Attributes
The data types of all attributes, including instance attributes and in particular bound data types, belong to the static
properties of a class. Therefore, in a LIKE addition, you can use the class component selector or reference
variables to refer to the visible attributes of a class without first creating an object. In this way, you can access the
properties of the public static attributes of global classes from every program.
Example
Reference to the data type of an instance attribute attr of a global class cl_global.
DATA dref TYPE REF TO cl_global.

DATA: f1 LIKE cl_global=>attr,
f2 LIKE dref->attr.
Boxed Components
Attributes declared as structures can be declared as static boxes using the BOXED addition, like substructures of
nested structures. With static boxes, initial value sharing results in reduced memory requirement for infrequently
used structures of regularly used objects. As a boxed component, a static box is a deep component administered
using an internal reference, like strings and internal tables.
3.1.3 Methods
Methods are internal procedures of a class that determine the behavior of an object. They can access all the
attributes of all instances of their class and can therefore change the status of an object. Methods have a
parameter interface, used by the system to pass values to them when they are called, and by which they can
return values to the caller. The private attributes of a class can only be changed using methods of the same class.
A method meth is declared in the declaration section of a class and is implemented in the implementation part of
the class using the processing block

METHOD meth.
...
ENDMETHOD.
As in all procedures, local data types and data objects can be declared in methods. Methods are called statically
using the expression meth( ... ) or dynamically using the statement CALL METHOD (Dynamic Invoke).
Instance Methods
Instance methods are declared using the METHODS statement. They can access all the attributes of a class and can
trigger all its events.
Static Methods
Static methods are declared using the CLASS-METHODS statement. This statement can access static attributes of a
class and is can trigger static events only.
Constructors
As well as the normal methods that are called explicitly, there are two special methods called constructor and
class_constructor, which are called automatically when an object is created or when a class component is
accessed for the first time.
Functional Methods
Functional methods are methods with any number of IMPORTING parameters and one RETURNING parameter.
Functional methods cannot just be called as standalone statements, but also as functional method calls in operand
positions for functions and expressions. Here they can be also be combined as method chainings.
3.1.3.1 Interface Parameters in Methods

Interface parameters in methods are input parameters (IMPORTING, CHANGING parameters) and output parameters
(EXPORTING, CHANGING, RETURNING parameters). In declarations with the statements
METHODS
CLASS-METHODS
EVENTS
CLASS-EVENTS
the following attributes are determined:

Passing parameters by reference or by value
With the exception of the return value (RETURNING parameters), parameters can be passed both by value or
reference. Passing by reference is standard with methods. If only a name p is specified in the parameter
declaration, the parameter is passed implicitly as a reference. If a VALUE(p) is specified instead, then the
parameter is passed as a value. The return value may only be passed as a value. Passing by reference can also
be explicitly specified with other parameters using REFERENCE(p). An IMPORTING parameter transferred by
reference, cannot be changed in the method.

Typing parameters

All parameters must be typed during declaration using the addition TYPE or the addition LIKE. The following entries
are allowed after TYPE as parameter types:

Optional parameters

All input parameters (IMPORTING, CHANGING parameters) can be defined in the declaration as optional parameters
using the additions OPTIONAL or DEFAULT. These parameters must not necessarily be transfered when the method
is called. With the addition OPTIONAL your parameter remains initialized according to type, while the addition
DEFAULT allows you to enter a start value.
3.1.3.2 The C Destructor
A destructor is a special method that is called automatically when an object is deleted. Destructors can be used to
release resources used by the object that are not included in garbage collection. ABAP Objects do not currently
have a destructor in which a regular ABAP processing block can be programmed.
For special cases and for internal use only, the predefined instance method destructor can be declared in the
public visibility section of a class:
PUBLIC SECTION.
METHODS destructor [NOT AT END OF MODE].
...
ENDCLASS.
In the implementation of the method destructor only one statement can currently be used:
METHOD destructor.
SYSTEM-CALL c-destructor 'name' USING attr.
ENDMETHOD.
ENDCLASS.
This means that the destructor makes it possible to call a C routine name when an object is deleted. The routine
must exist in the ABAP kernel to ensure that no syntax errors occur.
When the optional addition NOT AT END OF MODE is used, the destructor is not executed if the internal session is
closed anyway. A destructor is usually also executed at the end of a session and should mainly be used to release
external resources that are not released automatically when the session is closed.
When the C routine is called, attributes attr1, attr2, and so on, of the class of any complex data type can be
passed on to the routine. If multiple parameters are to be passed, an appropriate data type must be defined.
During the lifetime of an internal session, the time at which the method destructor is executed depends on when
the garbage collector is started. When an internal session is closed, the destructors that are not declared with the
addition NOT AT END OF MODE are executed for all objects. In the case of inheritance, the destructors of
subclasses are executed before the destructors of superclasses.
3.1.3.3 Kernel Methods
For internal use, kernel methods can be implemented in the ABAP kernel instead of in the ABAP language.
Introduction
Kernel methods allow you to directly call ABAP kernel functions implemented in C or C++. Kernel methods replace
the previous concepts of C calls and system calls. No new C calls or system calls need to be introduced.
Kernel methods offer the same checks and security features as normal ABAP methods. Except for the
Constructors and the C Destructor, all ABAP methods can be implemented as kernel methods. An ABAP method
can still be redefined as a kernel method and a kernel method can still be redefined as an ABAP method within a
path of the inheritance hierarchy.
For C developers who want to implement a kernel method, an API is available that allows simple, high-
performance, and secure access to arguments. Class-based exceptions also continue to be supported.
Defining Kernel Methods
Declaration in ABAP
A kernel method is declared in the same way as a normal ABAP method, in Class Builder or in the declaration
section of a local class. Whether a method is implemented as a kernel method is not important for the declaration.
In ABAP, this means that a kernel method can be used just like a normal ABAP method.
Implementation in ABAP
A method is specified as a kernel method in the implementation part of the class using the optional addition BY
KERNEL MODULE kmod1 kmod2 ... of the statement METHOD. kmod1, kmod2, ... are the names of kernel modules
that implement the method. The ABAP implementation of a kernel method must be empty, which means that there
cannot be any ABAP statements between METHOD and ENDMETHOD:
METHOD meth BY KERNEL MODULE kmod1 kmod2 ...
ENDMETHOD.
Constructors and the C Destructor cannot be implemented as kernel methods. There is a separate mechanism for
the C Destructor.
After KERNEL MODULE, you can specify a list of kernel modules kmod1, kmod2, ... Currently, you can only specify C
functions of the kernel for kmod1, kmod2, ... The list after KERNEL MODULE is evaluated by the compiler from left to
right. The first kernel module in the list that is registered in the kernel (see below) is used in the generation.
If no valid kernel module is found in the list, a syntax error occurs. There are still two standard C functions that can
appear at the end of the list: FAIL and IGNORE. If one of these functions is specified at the end of the list, then a
syntax error is avoided if the previous list does not contain a valid module. IGNORE is used to ignore the call of a
kernel method of this type (behavior as in an empty ABAP implementation) and, in the case of FAIL, a handleable
exception of the class CX_SY_DYN_CALL_ILLEGAL_METHOD is raised.
Examples
METHOD meth BY KERNEL MODULE xx_impl_630 xx_impl_620 xx_impl_610.
First, the kernel is searched for xx_impl_630. The kernel is then searched for nach xx_impl_620, and finally for
xx_impl_610. If none of these functions are found, a syntax error is raised.
METHOD meth BY KERNEL MODULE xx_impl_630 xx_impl_620 FAIL.
First, the kernel is searched for xx_impl_630. Then the kernel is searched for xx_impl_620. If neither of these
functions are found, a syntax error is not raised; a handleable exception of the class
CX_SY_DYN_CALL_ILLEGAL_METHOD is raised instead, when the method is called.
METHOD meth BY KERNEL MODULE xx_impl_620 xx_impl_610 IGNORE.
First, the kernel is searched for xx_impl_620. Then the kernel is searched for xx_impl_610. If none of the functions
are found, a syntax error is not raised; the empty ABAP implementation is called instead, when the method is
called.
Implementation in the Kernel
Currently, only C functions can be used as kernel modules of kernel methods. The C functions can have any
position in the kernel. No special includes from the ABAP runtime environment are required for implementing the C
function. The C functions must have a specific interface. The interface itself is wrapped by a macro called
ARGUMENTS. All required definitions and prototypes are in the include //src/include/abkmeth.h. This is the only
include needed for defining C functions for kernel methods.
Since C functions can be defined in C and C++ , you must use externC in C++:
#include "abkmeth.h"
...
externC void name_of_cmodule( ARGUMENTS )
{
...
}
A C function that implements a kernel method must be registered for the kernel method. If, after METHOD meth BY
KERNEL MODULE, you specify the name of a C function that was not registered for the kernel method, a syntax error
occurs (as mentioned above). You can register several C functions for a kernel method. The sequence of the
kernel modules kmod1, kmod2, ... specified in the list after METHOD meth BY KERNEL MODULE defines which of the
registered C functions is used. This allows downward-compatible further development of kernel methods.
To make changes to the registration active, you must recompile the destination lib of the project krn/runt and
relink the kernel.
Registration
C functions are registered in the signature file //src/krn/runt/abkmeth.sig using the following syntax for kernel
methods (all ABAP IDs must be specified in uppercase letters):
KERNEL_METHOD("CLASS","METH", cfunc,argcnt)
This definition registers the C function cfunc for the kernel method meth of a global class class. The C function
expects a number of argcnt arguments.
Kernel methods of local classes in class pools or other ABAP programs are registered using the following macros:
KERNEL_METHOD_CLASS_LOCAL("GCLASS","CLASS","METH",cmodule,argcnt)
KERNEL_METHOD_PROGRAM_LOCAL("PROG","CLASS","METH",cmodule,argcnt)
The technique is the same as with KERNEL_METHOD, except that you must specify the global class gclass for local
classes in class pools and the program prog for program-local classes.
Registering Arguments
All ABAP data objects (such as parameters, attributes, or global data) that are to be accessed in C functions for
kernel methods, are treated as arguments of the C function.
The argument list of a C function for a kernel method is not limited to the interface parameters of the ABAP
method and does not have to contain these completely. Before you access arguments within C functions for kernel
methods, these arguments must be registered.
The argcnt arguments must be registered immediately after the C function is registered using KERNEL_METHOD. A
single argument is defined (registered) using one of the following macros:
ARGUMENT_basetype(index,"name",type_kind,"type",read_write)
ARGUMENT_[C|N|X](index,"name",type_kind,"type",read_write,length)
ARGUMENT_P(index,"name",type_kind,"type",read_write,length,decimals)
ARGUMENT_STRUCT(index,"name",type_kind,"type",read_write,ctype)
These macros define an argument with the name name and an index index.
You must use basetype to assign the type of the ABAP data object according to the following table. If the
basetype is C, N, X, P, or STRUCT, you must specify more parameters than for other types.
basetype
ABAP Data Type Type in C
C c with specified length SAP_CHAR (*) [Length]
C_GENERIC c without specified length SAP_CHAR*
X x with specified length SAP_RAW (*) [Length]
X_GENERIC x without specified length SAP_RAW*
N n with specified length SAP_CHAR (*) [Length]
N_GENERIC n without specified length SAP_CHAR*
P p with specified length and decimals SAP_BCD (*) [Length]
P_GENERIC p without specified length and decimals SAP_BCD*
D d SAP_DATE*
T t SAP_TIME*
INT1 b SAP_INT1*
INT2 s SAP_SHORT*
I i SAP_INT*
F f SAP_DOUBLE*
DECFLOAT16 decfloat16 DecFloat16
DECFLOAT34 decfloat34 DecFloat34
STRING string StrRef*
XSTRING xstring StrRef*
TABLE All table types TABH_REF*
OBJ_REF
All object references
ObjRef*
DATA_REF
All data references
FldRef*
STRUCT
All structure types Registered type ctype*
ANY any void*
DATA data void*
SIMPLE simple void*
CSEQUENCE csequence void*
XSEQUENCE xsequence void*
NUMERIC numeric void*
CLIKE clike SAP_CHAR*

The macro parameters have the following meanings:
name is the ID for any ABAP data object in uppercase letters that could also be used in an ABAP
implementation of the kernel method. In particular, the ID can contain links with component selectors, for
example me->attr or struc-comp.
index is a sequential number from 1 to argcnt. The arguments are accessed using this index.
For type_kind you can specify either TYPE or TYPE_REF_TO.
type is the ID for any ABAP data type in uppercase letters that could also be used in an ABAP
implementation of the kernel method. type_kind and type are used to check the interface of the kernel
method in ABAP.
For read_write you can specify either READ or WRITE. This defines whether you have read or write access
to the argument and is evaluated in the access macros.
length is used to specify the length of all ABAP data types with a generic length for ARGUMENT_[C|N|X|P].
In characters for c and n and in bytes for x and p.
For ARGUMENT_P you use decimals to specify the number of decimal places.
For ARGUMENT_STRUCT you use ctype to specify a suitable C type. This type should be generated from an
ABAP type definition using saphfile.
Accessing Arguments
After registering the arguments, you can use the following macros to access them within the C function. With the
exception of the direct access to the data control block, the access macros do not require any includes from the
ABAP runtime environment.
ARGUMENT_basetype_READ(index,"name");
This macro returns the read address of an argument with the type const ctype, where ctype is defined by
basetype according to the above table. The index and name of the argument must be passed. You must specify
additional parameters for the generic types (see below). You only need the index to access the argument.
However, to make the C function more legible and ensure that additional consistency checks can be executed, you
must also specify the name. If the kernel is compiled in debugging mode, the system executes a consistency
check between index and name; the specified C type and ABAP type of the argument are also checked. In the
case of an error, an appropriate ABAP runtime error is triggered (KMETH_INVALID_ARGUMENT_ID,
KMETH_INVALID_ARGUMENT_NAME, or KMETH_INVALID_CTYPE_LENG). No checks are made in the
optimized kernel.
ARGUMENT_basetype_WRITE(index,"name");
This macro has the same semantics as ARGUMENT_basetype_READ. However, the system returns the write
address. The system also checks whether the argument was defined as a write argument. If you try to write
access a read-only argument (for example, a constant), this triggers the ABAP runtime error
KMETH_ARGUMENT_READ_ONLY.
ARGUMENT_[C|N]_READ(index,"name",lengthU);
ARGUMENT_[C|N]_WRITE(index,"name",lengthU);
ARGUMENT_X_READ(index,"name",lengthR);
ARGUMENT_X_WRITE(index,"name",lengthR);
With these macros you must specify the expected length in bytes lengthR or in characters lengthU for the generic
types c, x, and n
ARGUMENT_P_READ(index,"name",lengthR,decimals);
C_POINTER %_c_pointer void**
ARGUMENT_P_WRITE(index,"name",lengthR,decimals);
With these macros you must specify the expected length in bytes (lengthR) and the number of decimal places
(decimals) for the generic type p.
ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_READ(index,"name",size_tU);
ARGUMENT_[C_GENERIC|N_GENERIC|CLIKE]_WRITE(index,"name",size_tU);
ARGUMENT_X_GENRIC_READ(index,"name",size_tR);
ARGUMENT_X_GENERIC_WRITE(index,"name",size_tR);
With these macros you must specify a variable of the type size_tU or size_tR, containing the length in bytes or
characters, for the types C_GENERIC, X_GENERIC, N_GENERIC, and CLIKE.
ARGUMENT_P_GENERIC_READ(index,"name",size_tR,decimals);
ARGUMENT_P_GENERIC_WRITE(index,"name",size_tR,decimals);
With these macros you must specify a variable decimals (for the decimal places) as well as the length size_tR
for the type P_GENERIC.
ARGUMENT_STRUCT_READ(index,"name",ctype);
ARGUMENT_STRUCT_READ(index,"name",ctype);
With these macros you must specify a suitable C typectype for all structured types STRUCT.
ARGUMENT_C_POINTER(index,"name");
This macro is available specifically for the type %_c_pointer. This type is a special internal ABAP type that has
exactly the byte length of a C pointer (4, 8, or 16 bytes, depending on platform). The type is always mapped to the
predefined ABAP type x. The macros for the type X or X_GENERIC are not used due to the variable length and
platform-dependency.
ARGUMENT_IS_SUPPLIED(index,"name");
This macro has the same semantics as the logical expression IS SUPPLIED in ABAP. The same consistency
checks are executed as for ARGUMENT_READ.
ARGUMENT_DATA(index,"name",ctype);
This macro returns the data control block with the C type const DATA *. The same consistency checks are
executed as for ARGUMENT_READ. The macro is only active if the include //src/include/abdata.h of the ABAP
runtime environment was included.
Raising Exceptions
C functions that implement kernel method can raise class-based exceptions.
Registering Exceptions
The relevant global exception classes must be registered with an extension of //src/include/abexcpc.h. Local
exception classes cannot be registered.
The exception class is declared in //src/include/abexcpc.h and any text IDs are defined:
//src/include/abexcpc.h
...
CX_ABSTR (CX_..., "CX_...")
CX_TXTID (CX_..._bar, CX_..., "BAR") /* special text for class */
...
Classes can also be declared with their standard text only:
//src/include/abexcpc.h
...
CX_CLASS (CX_..., "CX_...") /* class with standard text */
...
The exact documentation is in the file //src/include/abexcpc.h.
You must extend the file //src/include/abexcpa.h so that any attributes of an exception class in a C function
can be populated; you must specify the name, internal type (according to //src/include/abtypes.h) and the
byte length:
//src/include/abexcpa.h
...
CX_ATTR (CX_..._attr1, CX_..., "ATTR1", TYPCSTRING, sizeofR(StrRef))
CX_ATTR (CX_..._attr2, CX_..., "ATTR2", TYPC, LEN_UC2RAW(30))
...
Finally, you must register exceptions as well as arguments in the file //src/krn/runt/abkmeth.sig. This is not
forced but, during the syntax check, only registered exceptions are checked for their existence:
//src/krn/runt/abkmeth.sig
...
EXCEPTION(CX_...)
...
Raising Exceptions
A C function can raise an exception by calling the following macros consecutively:
EXCEPTION_CREATE(CX_..._bar);
EXCEPTION_SET_CSTRING(CX_..._attr1, value, valueLength);
EXCEPTION_SET_C (CX_..._attr2, value, valueLength);
EXCEPTION_RAISE();
Within the macros EXCEPTION_CREATE or EXCEPTION_RAISE, a long jump to Extri always takes place, which means
that the C function that implements the kernel method is exited in a long jump and the ABAP runtime environment
takes control. Therefore, the C function should release its temporary memory before raising an exception. If the
exception is caught in ABAP using CATCH without the INTO addition, the long jump takes place in
EXCEPTION_CREATE. If the exception is caught with the INTO addition (the exception object is used) or not at all, the
long jump takes place in EXCEPTION_RAISE.
The exceptions are processed in the runtime environment, as if they were raised in ABAP and the same dynamic
checks are executed.
Currently, the following macros, which can be extended if necessary, are available for setting exception attributes.
Strings, integer and C fields are supported. See the above sequence for use.
EXCEPTION_SET_CSTRING_UC
EXCEPTION_SET_C
Value with length specified
EXCEPTION_SET_C_UC
EXCEPTION_SET_INT
Value with null termination
Auxiliary Program for Kernel Methods
The ABAP program RSKMETH serves as a browser for the registration of kernel modules. You can use it to
ascertain which C functions are registered for which kernel methods and which arguments/exceptions are
registered for these functions. This is helpful when analyzing syntax errors, since kernel methods process
information that only exists in the kernel modules.
Example
The following example is a simplified calculation class for floating decimal place numbers. The class has an
instance attribute in which the last result of each calculation is stored. A method executes a division and is
implemented as a kernel method. If the divisor is zero, the method triggers a class-based exception.
Declaration Section of the Class in ABAP
CLASS cl_my_calculation DEFINITION ...
...
DATA last_result TYPE decfloat16.
...
METHODS div
IMPORTING p_dividend TYPE decfloat16 p_divisor TYPE decfloat16
RETURNING VALUE(p_result) TYPE decfloat16.
...
ENDCLASS.
Signature File //src/krn/runt/abkmeth.sig in the kernel
...
KERNEL_METHOD(CL_MY_CALCULATION, DIV, xx_myDiv,4)
ARGUMENT_F(1, "P_DIVIDEND", TYPE, "F", READ)
ARGUMENT_F(2, "P_DIVISOR", TYPE, "F", READ)
ARGUMENT_F(3, "P_RESULT", TYPE, "F", WRITE)
ARGUMENT_F(4, "ME->LAST_RESULT",TYPE, "F", WRITE)
EXCEPTION("CX_MY_DIV_BY_ZERO")
...
C++ source code //src/krn/.../mycalc.cpp in the kernel
#include "abkmeth.h"
...
externC void xx_myDiv( ARGUMENTS ){

const SAP_DOUBLE *const dividend = ARGUMENT_F_READ(1,"P_DIVIDEND");
const SAP_DOUBLE *const divisor = ARGUMENT_F_READ(2,"P_DIVISOR");
SAP_DOUBLE *result = ARGUMENT_F_WRITE(3,"P_RESULT");
SAP_DOUBLE *last_result = ARGUMENT_F_WRITE(4,"ME->LAST_RESULT");

if( 0 == *divisor )
{
EXCEPTION_CREATE(CX_MY_DIV_BY_ZERO);
EXCEPTION_RAISE();
}

*result = *dividend / *divisor;
*last_result = *result;

}
Implementation Section of the Class in ABAP
CLASS cl_my_calculation IMPLEMENTATION.
...
METHOD div BY KERNEL MODULE xx_myDiv.
ENDMETHOD.
...
ENDCLASS.
3.1.4 Constructors
Constructors are special methods that produce a defined initial state for objects and classes. The state of an
object is determined by its instance attributes and static attributes. You can assign contents to attributes using the
VALUE addition in the DATA statement. Constructors are necessary when you want to set the initial state of an
object dynamically.
Like normal methods, there are two types of constructor: instance constructors and static constructors.
Special rules apply to constructors during inheritance. These rules are not described in this document, but can be
found here.
Instance Constructors
Each class has one instance constructor. This is a predefined instance method of the constructor class. If you
want to use the instance constructor, the constructor method must be declared in a visibility area of the class
using the METHODS statement, and implemented in the implementation section. In global classes, the instance
constructor can be declared in the public visibility area only, for technical reasons. In local classes, the visibility
area in which the instance constructor can be declared must be more general or equal to the instantiability defined
by the addition CREATE of the CLASS statement, where the most specialized area is recommended. Unless it is
explicitly declared, the instance constructor is an implicit method, which inherits and accesses the interface from
the instance constructor in the superclass.
Instance constructors are called once for each instance. They are called automatically, immediately after you have
created an instance using the CREATE OBJECT statement. It is not possible to call an instance constructor directly
using the constructor( ... ); see super->constructor( ... ) in the inheritance.
An instance constructor can contain an interface with IMPORTING parameters and exceptions. You define the
interface using the same syntax as for normal methods in the METHODS statement. The fact that there are no
exporting parameters shows that constructors only exist to define the state of an object and have no other
function. To pass parameters and handle classic exceptions, use the EXPORTING and EXCEPTIONS additions of the
CREATE OBJECT statement.
Static Constructors
Each class has a single static constructor. This is a predefined public static method of the constructor class. If
you want to use the static constructor, you must declare the static method class_constructor in the public
section of the declaration part of the class using the CLASS-METHODS statement, and implement it in the
implementation part. The static constructor has no interface parameters and cannot raise exceptions. Unless you
implement it explicitly, it is merely an empty method.
The static constructor is called once per class and internal session. The static constructor of a class class is
called automatically before the class is accessed for the first time. The static constructor is always called
immediately before the class is accessed, with one exception: If your first access to the class is to address a static
attribute, the static constructor is executed at the beginning of the processing block (dialog module, event block,
procedure) in which access takes place.
Notes
The point at which the static constructor is called has not yet been finalized. We can currently ensure only
that it will be called before the class is accessed for the first time. For this reason, static methods may be
executed before the static constructor was ended.
The execution sequence of static constructors is dependent on the program flow. Static constructors must
be implemented so that they can be executed in any sequence.
3.1.4.1 Visibility of Instance Constructors
For technical reasons, the system declares the instance constructor of a class in a visibility area; it is therefore
theoretically visible to the appropriate users. However, an instance constructor is only executed during the creation
of an object of this class using CREATE OBJECT. Therefore the instance constructor is only visible to those users of
a class that can also create objects of this class.
The additions CREATE PUBLIC|PROTECTED|PRIVATE of the statement CLASS determine whether every user, only
the heirs, or just the class itself can create objects of the class. This means that these additions define the actual
visibility of the instance constructor. Therefore the following applies:
The instance constructor of a class defined using CREATE PUBLIC can be called by any user.
The instance constructor of a class defined using CREATE PROTECTED can only be called by the class itself
and its subclasses.
The instance constructor of a class defined using CREATE PRIVATE can only be called by the class itself.
This has the following important consequence:
If a class was defined using CREATE PRIVATE, only the class itself can instantiate itself. Subclasses of this class
cannot even instantiate themselves, because they would have to call the superclass constructor using CALL
super->constructor (also see Inheritance and Instance Creation).
3.1.5 Events
In ABAP Objects, events are declared as components of classes. SAP makes a distinction between instance
events and static events. Triggers and handlers can be objects and classes, depending on whether they are
instance events, static events, or event handlers.
Instance events
Instance events are declared using the EVENTS statement. They can only be triggered in instance methods.
Static events
Static events are declared using the CLASS-EVENTS statement. All methods (instance or static) can trigger them,
but only static events can be triggered by static methods.
3.1.6 Data Types and Constants
Data Types
Independent Types
You can use the TYPES statement to define any number of your own ABAP data types within a class. Types are
not instance-specific and are only available once for all the objects in the class.
In particular, it is possible to define data types in the public visibility section of global classes, which makes the use
of type groups in this context obsolete.
Bound Data Types
Bound data types that occur as properties of instance or static attributes also belong to the static attributes of a
class. After a LIKE addition, the class name can be used to access the properties of instance attributes
(exceptions to this rule are the statements ASSIGN ... CASTING and SELECT-OPTIONS ... FOR). In addition, a
reference variable can be used with an object component selector without the object having previously been
generated.
Constants
Constants are special static attributes for which values are specified when they are declared. These values cannot
be changed later. Use the CONSTANTS statement to declare constants. Constants are not instance-specific - they
are only available once for all the objects in the class.
In particular, it is possible to declare constants in the public visibility section of global classes, which makes the
use of type groups in this context obsolete.
4 Inheritance
The concept of inheritance allows you to derive new classes from existing classes. To do this, you use the
INHERITING FROM addition of the CLASS ... DEFINITION. The new class adopts or inherits all components of the
existing class. The new class is called subclass, and the existing class is called superclass.
If you make no further declarations, a subclass contains exactly the components of the superclass. However, only
the components of the public, protected, and package visibility section of the superclass are visible in the
subclass. Although the private components of the superclass are also contained in the subclass, they are not
visible. In a subclass, you can declare private components with the same name as the corresponding components
of the superclass. Each class works with its private components. As long as a method inherited from the
superclass is not redefined, it uses the private attributes of the superclass and not the possible subclass attributes
of the same name.
If the superclass does not have a private visibility section, the subclass is an exact copy of the superclass. You
can, however, add further components to the subclass. These components are used to specialize the subclass in
relation to the superclass. If a subclass is then used as the superclass for a new class, you can then define a
further level of specialization.
Each class can have several direct subclasses, but only one direct superclass. ABAP Objects applies the principle
of single inheritance. If subclasses inherit from superclasses that are subclasses themselves, all classes involved
represent an inheritance tree whose specialization increases the more deeper hierarchy levels are added.
Specialization decreases the closer a level is located to the root node of the inheritance tree. The root node of all
inheritance trees in ABAP Objects is the predefined empty class object. This class is the most generic class
because it does not contain attributes or methods. When you define a new class, you must not explicitly specify
this class as a superclass because it always exists implicitly. In the inheritance tree, two neighboring nodes are
known as the direct superclass and subclass, while all preceding and succeeding nodes are collectively referred to
as superclasses and subclasses. The declaration of the components of a subclass is distributed among all
superclasses of the inheritance tree.
Programming Guideline
Avoid using deep inheritance hierarchies
4.1 Redefining Methods
Each subclass contains the components of all classes that are located between this class and the root node in the
inheritance tree. The visibility of a component is always the same and cannot be changed. However, it is possible
to redefine the public and protected instance methods of all preceding superclasses using the REDEFINITION
addition of the METHODS statement in order to adjust them to the requested specialization. The interface of a
redefined method cannot be changed. The method is merely reimplemented under the same name. Constructors
cannot be redefined; instead, special rules apply.
The method declaration remains with the superclass, and its previous implementation is also persisted there. The
implementation of the redefinition is generated additionally with the subclass and obscures the implementation of
the superclass. A redefined method works with the private attributes of the subclass and not with possible private
superclass attributes of the same name.
Each reference that points to a subclass object uses the redefined method, even if it was typed with reference to a
superclass. In particular, this also applies to the self reference me. For example, if a superclass method m1
contains a call [me->]m2( ) or and if m2 is redefined in a subclass, the call of m1 in an instance of the superclass
causes the original method m2 to be executed and the call of m1 in an instance of the subclass causes the
redefined method m2 to be executed.
Within a redefined method, super->meth can be used to access the obscured method, for example to adopt and
supplement its functions.
4.2 Abstract and Final Methods and Classes
Using the ABSTRACT and FINAL additions of the METHODS and CLASS statements, you can define abstract and final
methods or classes.
Abstract methods are declared in abstract classes and cannot be implemented in the same class but only in a
subclass of the inheritance tree. Abstract classes can consequently not be instantiated. A non-abstract method is a
concrete method. Except for the instance constructor, the concrete instance methods of a class can also call its
abstract methods.
Final methods cannot be redefined in subclasses. Final classes cannot have any more subclasses and constitute
the final node of an inheritance tree.
Note
In classes that are abstract and final at the same time, only the static components can be used. Instance
components can be declared, but these cannot be used. For this reason, it is recommended that you specify both
ABSTRACT and FINAL only for static classes.
4.3 Inheritance and Polymorphism
Since a subclass contains all components of all superclasses along the inheritance tree and the interfaces of
methods cannot be changed, a reference variable typed with reference to a superclass or to an interface
implemented by a superclass may contain references to objects of all subclasses of this superclass. This means
that the content of a reference variable typed with reference to a subclass can always be assigned to reference
variables typed with reference to one of its superclasses or the interfaces of these superclasses (Up Cast). In
particular, the target variable can always be typed with reference to the class object.
A static user can use a reference variable to address the components visible to it, which are contained in the
superclass to which the reference variable refers. This means that it cannot address any specializations that have
been added to the subclasses. With dynamic accesses, however, all components can be addressed.
When an instance method is redefined in one or more subclasses, different implementations of the method can be
executed after a method call using the same reference variable, depending on where the class of the referenced
object is located in the inheritance tree. The feature that different classes have the same interface and can
therefore be addressed using reference variables of one type is called polymorphism.
4.4 Inheritance and Interfaces
Interfaces are independent constructs in ABAP Objects that support polymorphism of classses. The polymorphism
of interfaces is based on the fact that each class implementing an interface can implement the methods of that
interface differently. To the outside world, all interface components look similar which is why interface reference
variables can point to objects of all classes that implement the associated interface. The interface concept exists
independently of and in addition to the inheritance concept.The classes of an inheritance tree can implement any
number of interfaces but each interface can be implemented only once in each inheritance tree. This ensures that
each interface component comp has a unique name in the entire inheritance tree intf~icomp and that, starting
with the class that implements it, it is contained in all subclasses.
Interface reference variables that can point to a class of the inheritance tree can also point to all subclasses.
Having been implemented, interface methods are fully functioning components of a class and can be redefined in
subclasses.
4.5 Inheritance and Visibility
You cannot change the visibility area to which a component is assigned using inheritance. Component visibility
affects inheritance as follows:
Public components
The public visibility area of a subclass consists of all its own public components plus the public components of all
its superclasses. From outside the class, public components are visible without restrictions.
Protected components
The protected visibility area of a subclass consists of all its own protected components plus the protected
components of all its superclasses. The protected section is visible only in the class itself and in all its subclasses.
Viewed from outside, protected is the same as private.
Private components
The private visibility area of a subclass includes only the private components of this class. They are visible only in
this class. The private components of superclasses cannot be used in subclasses. Only methods inherited from
superclasses use (provided they have not been redefined) the private attributes of the superclass (even if the
subclass has private attributes with the same name).
Example of protected components
Within a subnode in the inheritance tree, you can always access the protected components of superclasses. The
classes involved, such as the static types of reference variables, must however be part of the inheritance tree.
In the following example, the reference variables lrefx and lref2 can see the protected components of cx in the
context of the subclass c2. The static type of lref1 is c1 and is in another subnode of the inheritance tree. It
cannot see any protected components of cx, in the context of c2. In a stricter model (C++ or Java), access in this
example would only be possible using lref2. Access using lrefx would not be permitted, since it would involve
classes (not subclasses) seeing protected components from outside. At present, ABAP extends the view of lrefx
but only in a specific context. We intend, however, to introduce a stricter model and forbid access using lrefx. For
this reason, you should not use this option; it causes a warning to be displayed in the extended program check.
CLASS cx DEFINITION.
PROTECTED SECTION.
METHODS mx.
ENDCLASS.

CLASS cx IMPLEMENTATION.
METHOD mx.
...
ENDMETHOD.
ENDCLASS.

CLASS c1 DEFINITION INHERITING FROM cx.
...
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM cx.
PUBLIC SECTION.
METHODS m2.
ENDCLASS.

METHOD m2.
DATA: lrefx TYPE REF TO cx,
lref2 TYPE REF TO c2,
lref1 TYPE REF TO c1.
lrefx->mx( ). <--- Warning!!
lref2->mx( ).
lref1->mx( ). <--- Error!!
ENDMETHOD.
ENDCLASS.
4.6 Inheritance and the Component Namespace
A subclass contains all components of all its superclasses. Only the public and the protected components are
visible. This is why all public and protected components of an inheritance tree are located in a single namespace
and must have unique names. Private components, on the other hand, must only be named uniquely within a
class.
When methods are redefined, the newly implemented method obscures the identically named method of the
superclass. As soon as the method is redefined, it replaces the old method to ensure that the name remains
unique. The pseudo reference super-> can be used in subclasses to access a method of the direct superclass
which is hidden as a result of a redefinition.
4.7 Inheritance and Static Components
Static components, like all components, exist only once in each inheritance tree, and can be used as of the
declaring class:
A subclass can access all non-private static components of its superclasses. The class in which the static
component is declared is always the class that is addressed.
From outside, the class component selector can be used to access all visible static components. Each
class can be specified in which the component exists (that is, the declaring class and each subclass).
Regardless of the class name used in the class component selector, however, the class in which the
component is declared is addressed.
The class in which the component is declared is addressed, whether the static component is used internally or
externally. This is important for:
Calling the static constructors.

Static constructors are called the first time you address a class. If you address a static component declared
in a superclass using the class name of a subclass, only the static constructor of the superclass is called.
Access to the static attributes

A subclass has access to the content of all non-private static attributes of all superclasses. Conversely, a
superclass shares its public and protected static attributes with all of its subclasses. When inherited,
therefore, static attributes are not assigned to a single class; instead they are assigned to the subtree of the
inheritance tree that consists of all subclasses of the defining class. Changes to the values are visible in all
involved classes, regardless of the class used to address an attribute.
The registration of event handlers.

If an event handler is declared for a static event of a subclass inherited from a superclass, it can react to
this event only if it is triggered by a method of the subclass or one of its subclasses. If the event is triggered
in a static method of a superclass, it is not handled, even if the method is called in a subclass or if the name
of the subclass is specified.
Example
Calls a static method of a superclass using the name of a subclass. Before the method is executed, the static
constructor of the superclass is executed, but not the static constructor of the subclass. The method returns the
value set in the superclass.
PUBLIC SECTION.
CLASS-DATA a1 TYPE string.
CLASS-METHODS: class_constructor,
m1 RETURNING value(r1) LIKE a1.
ENDCLASS.

METHOD class_constructor.
a1 = 'c1'.
ENDMETHOD.
METHOD m1.
r1 = a1.
ENDMETHOD.
ENDCLASS.

PUBLIC SECTION.
CLASS-METHODS class_constructor.
ENDCLASS.

a1 = 'c2'.
ENDMETHOD.
ENDCLASS.

DATA v1 TYPE string.

START-OF-SELECTION.
v1 = c2=>m1( ).
Example
This example shows how a subclass is used to change a static attribute of a superclass, and how the change is
visible in a subclass of a different path in the inheritance tree.
PUBLIC SECTION.
CLASS-DATA a1 TYPE string.
ENDCLASS.

...
ENDCLASS.

...
ENDCLASS.

c11=>a1 = 'Hello Sister'.

MESSAGE c12=>a1 TYPE 'I'.
Example
For an example of static events, see Inheritance Events.
4.8 Inheritance and Constructors
There are special rules governing constructors in inheritance.
Instance Constructors
Each class has an instance constructor called constructor. This is an exception to the rule that states that
component names along a path in an inheritance tree must be unique. The instance constructors of the various
classes in an inheritance tree, however, are fully independent of one another.
Instance constructors of superclasses cannot be redefined in subclasses.
Instance constructors cannot be called explicitly using constructor( ... ).
This means that no naming conflicts can occur.
The instance constructor is called when an object is created using the command CREATE OBJECT. Since a
subclass contains all of the visible attributes of its superclasses, which can also be set by instance constructors,
the instance constructor of a subclass has to ensure that the instance constructors of all of its superclasses are
also called. This requires that the instance constructor of each subclass contains a super->constructor call of
the instance constructor of the direct superclass even if it is not explicitly declared. The only exception to this rule
are direct subclasses of the root node OBJECT.
In superclasses without an explicitly defined instance constructor, the implicit instance constructor is called. This
automatically ensures that the instance constructor of the immediate superclass is called.
When instance constructors are called, all of their non-optional input parameters must be populated as follows:
Population for CREATE OBJECT

Starting from the class of the created objects, the first explicitly defined instance constructor in the
associated path of the inheritance tree is respected. This is the instance constructor of the class itself or the
first explicitly defined instance constructor of a superclass.
Population for super->constructor( ... )

Starting from the direct superclass, the first explicitly defined instance constructor in the associated path of
the inheritance tree is respected.
The interface of the first explicitly defined instance constructor is populated in the same way as with a normal
method. This means that:
If no input parameters exist, no parameters are passed.
Optional input parameters can be populated using EXPORTING.
Non-optional input parameters must be populated using EXPORTING.
If there are no explicitly defined instance constructors in the path of the inheritance tree below the root class
object, no parameters are passed.
In both CREATE OBJECT and super->constructor( ... ), the next available explicit instance constructor must
be considered, and, if it has an interface, values to passed to it. The same applies to exception handling for
instance constructors. When working with inheritances, a precise knowledge of the entire inheritance tree is
required. When a class at the bottom of the inheritance tree is instantiated, it may be necessary to pass
parameters to the constructor of a class that is much nearer the root node.
The instance constructor of a subclass is divided into two parts by the call super->constructor( ... )
(demanded by the syntax). In the statements before the call, the constructor behaves like a static method, which
means that the self reference me-> cannot be used and the constructor does not have access to the instance
components of its class. me-> cannot be used and instance components addressed until after the call The
statements before the call are used to determine the actual parameters for the interface of the instance constructor
of the superclass. Only static attributes or other visible data can be used for this.
When a subclass is instantiated, therefore, a nested call of the instance constructors from the subclass to the
superclasses takes place. Here, however, the instance attributes can only be addressed in the lowest nesting level
(which is the top superclass). When the constructors of the lower subclasses are revisited, their instance attributes
can be addressed there successively too.
The methods of subclasses are not visible in constructors. If an instance constructor calls an instance method of
the same class using the implicit self reference me, the method is called as it is implemented in the class of the
instance constructor, and not in any redefined form that may occur in the subclass being instantiated. This is an
exception to the rule that states that, when instance methods are called, the implementation is called in the class
to whose instance the reference points.
Static Constructors
Every class has a static constructor called class_constructor. With respect to the namespace within an
inheritance tree, the same applies to static constructors as to instance constructors.
The first time a subclass is addressed in a program, the static constructor is called. However, before it can be
called, the static constructors of all of its superclasses must already have been executed. A static constructor may
only be called once per program. Therefore, when subclass is first addressed, the system looks for the next
highest superclass whose static constructor has not yet been called. It calls the static constructor of that class,
followed by those of all classes between that class and the subclass addressed.
4.9 Inheritance and Instantiation
If you instantiate a subclass you instantiate all the superclasses at the same time, whereby the initialization of
superclass attributes is ensured by the call of the superclass constructors, as described in Inheritance and
Constructors.
For each individual class, the CREATE PUBLIC|PROTECTED|PRIVATE additions to the CLASS statement control who
can create an instance of the class or, in other words, can call its instance constructor.
This has the following consequences:
If you defined a superclass in a path of the inheritance tree using the CREATE PRIVATE addition, outside
users cannot instantiate a subclass, and a subclass cannot even instantiate itself, because it has no access
to the instance constructor of the superclass.
It would therefore also be useful to apply the FINAL addition to a class that was defined using the CREATE PRIVATE
addition, in order to prevent a derivation of subclasses. Otherwise subclasses of such superclasses have the
implicit CREATE NONE addition.
The only exception to this rule is if a superclass that can be privately instantiated offers its friendship to its
subclasses. The direct route is rarely the case here because the superclass must know its subclasses in order for
it to be possible. However, a superclass can also offer friendship to an interface which, in turn, can be
implemented by its subclasses.
Conversely, you cannot create objects of subclasses in their superclass, if these are declared using CREATE
PROTECTED or CREATE PRIVATE, unless they are friends of its subclasses.
Overview of all cases
Superclass with no addition or CREATE PUBLIC
Whether a friend of the superclass or not, subclasses can have anyCREATE addition. Without addition they inherit
the attribute CREATE PUBLIC. The superclass instance constructor is visible to everyone. The subclass controls the
visibility of its own instance constructor, independently of the superclass.
Superclass with CREATE PROTECTED addition.
Whether a friend of the superclass or not, subclasses can have anyCREATE addition. Without addition they inherit
the attribute CREATE PROTECTED. The superclass allows its subclasses unlimited instantiation and therefore also
the publishing of its protected instance constructor.
Superclass with CREATE PRIVATE addition
Subclass is not a friend of the superclass
The subclass has the implicit addition CREATE NONE. Because nobody other than the superclass itself can call its
instance constructor, the subclass cannot be instantiated. None of the CREATE additions is permitted, because this
would always lead to the unauthorized publishing of the superclass constructor.
Subclass is a friend of the superclass
If the subclass has no addition, it inherits the attribute CREATE PRIVATE. However, all CREATE additions are
permitted. As a friend, the subclass can publish the superclass's private constructor in any form.
4.10 Inheritance and Events
After its declaration in a superclass, an event is known in all subclasses of the inheritance tree in which it is visible,
and can be triggered in the methods there.
An event handler can be declared with reference to all classes of the inheritance tree in which the event is visible
for the event handler. However, it can only handle events which are triggered in classes which more specific or the
same as the class for which it is declared. If the event is triggered in a method of a superclass of the class, for
which an event handler is declared it cannot handle it.
Note the latter especially when triggering static events in static methods, since a static method is always executed
in the class in which it was declared (also refer to Inheritance and Static Components).
Note
For event handlers for events declared in interfaces, the above applies correspondingly to the class in which the
interface is bound
Example
Refer to Inheritance Events.
5 Interfaces
The components of a class are divided into visibility sections, and this forms the external point of contact between
the class and its user. For example, the public components of a class define its public scope, since all of its
attributes and method parameters can be addressed by all users. The protected components form an interface
between the class and those classes that inherit from it (subclasses).
Interfaces are independent structures that allow you to enhance the class-specific public points of contact by
implementing them in classes. Different classes that implement the same interface can all be addressed in the
same way. Alongside inheritance, interfaces provide one of the pillars of polymorphism, since they allow a single
method within an interface to behave differently in different classes. Interface reference variables allow users to
address different classes in the same manner. Interfaces can also be nested.
Defining Interfaces
Like classes, you define interfaces either globally in the repository or locally in an ABAP program.
Interface Components
You can define exactly the same components in an interface as in a class.
Implementing Interfaces
Unlike classes, interfaces do not have instances. Instead, interfaces are implemented by classes. The INTERFACES
statement in the declaration part of a class is used to implement interfaces in a class. This statement may only
appear in the public section of the class, that is, after PUBLIC SECTION. You can modify some interface
components to meet the requirements of the class. For example, you can identify methods as abstract or final, or
you can assign initial values to attributes.
When you implement an interface in a class, the components of the interface are added to the other components
in the public section. A component comp of an interface intf can be addressed as though it were a member of the
class under the name intf~comp.
The class must implement the methods of all interfaces implemented in it. The implementation part of the class
must contain a method implementation for each interface method meth:

METHOD intf~meth.
...
ENDMETHOD.
Instead of being specified by intf~meth, the method can also be specified by an alias defined using ALIASES.
Interfaces can be implemented by different classes. Each of these classes is extended by the same set of
components. However, the methods of the interface can be implemented differently in each class.
Interfaces allow you to use different classes in a uniform way using interface reference variables (polymorphism).
Interfaces that are implemented in different classes extend the public scope of each class by the same set of
components. If a class does not have any class-specific public components, the interfaces define the entire public
face of the class.
Interface Reference Variables
You use object references in object reference variables to access objects. Instead of creating reference variables
with reference to a class, you can also create them with reference to an interface. This kind of reference variable
can contain references to objects of classes that implement the corresponding interface. A reference variable obj
with reference to an interface intf is declared with the statement DATA obj TYPE REF TO intf. This reference
variable allows programs access to precisely those components defined in the interface, that is, the components of
an object that have been added to the class-specific components by implementing the interface.
Accessing Objects Using Interface References
To generate an object of the class class, you must first declare a reference variable cref with reference to the
class. If the class class implements an interface intf, you can assign the class reference variable cref to the
interface reference variable iref as follows:
iref = cref.
The reference in iref now points to the same object as the reference in cref.
It is also possible to directly generate an object to which the interface reference variable points initially. In this
case, the TYPE addition of the statement CREATE OBJECT must be used to specify a class that implements the
interface.
CREATE OBJECT iref TYPE class.
If the interface intf contains an instance attribute attr and an instance method meth, you can address the
interface components as follows:
Using the class reference variable (not recommended)
Accessing an attribute attr: cref->intf~attr
Calling a method meth: cref->intf~meth
Using the interface reference variable (recommended):
Accessing an attribute attr: iref->attr
Calling a method meth: [CALL METHOD] iref->meth
Accessing the Static Components of Interfaces
As far as the static components of interfaces are concerned, you can only use the interface name to access
constants.
Accessing a constant const: intf=>const
For all other static components of an interface, you can only use object references or the class class that
implements the interface.
Accessing a static attribute attr:class=>intf~attr
Calling a static method meth: [CALL METHOD] class=>intf~meth
5.1 Nesting Interfaces
Interfaces can be nested. An interface can include one or more interfaces as components, which can contain
interfaces themselves. An interface that includes another interface is called a compound interface. An interface
nested within an interface is called a component interface. An interface that does not contain any compound
interfaces is called an elementary interface.
All interface components of a compound interface have the same level. If a compound interface i3 contains
another compound interface i2, its interface component i1 becomes interface component of i3. A compound
interface includes each interface component exactly once. A component interface exists only once even if it is
used again as a component of another component interface.
The statement INTERFACES is used for nesting interfaces within an interface definition:
INTERFACE i3.
INTERFACES: i1, i2 ...
ENDINTERFACE.
Here the interface i3 consists of its components and the interfaces i1 and i2. In the compound interface the
components of the component interfaces are visible using the interface component selector (~). Within the above
definition of i3, expressions such as i1~comp or i2~comp are possible. However, you can define your own names
using the ALIASES statement.
Using Alias Names
Within interface definitions, the statement ALIASES can be used to assign alias names to the components of
component interfaces, and therefore make those nested to a depth greater than one level visible within the
interface definition.
INTERFACE i2.
INTERFACES i1.
ALIASES alias21 FOR i1~comp1.
ENDINTERFACE.

INTERFACE i3.
INTERFACES i2.
ALIASES alias31 FOR i2~alias21.
ALIASES alias32 FOR i2~comp2.
ENDINTERFACE.
Accessing Interface Reference Variables
Reference variables typed with reference to a compound interface can be assigned reference variables typed with
reference to one of the component interfaces ( up cast). The latter can be used to address the components of the
component interfaces. The opposite case cannot be checked statically and must take place with the casting
operator (?=) (down cast).
INTERFACE i1.
DATA comp1.
ENDINTERFACE.

INTERFACE i2.
DATA comp2.
INTERFACES i1.
ENDINTERFACE.

INTERFACE i3.
INTERFACES i2.
ENDINTERFACE.

DATA: iref1 TYPE REF TO i1,
iref2 TYPE REF TO i2,
iref3 TYPE REF TO i3.

iref2 = iref3.
iref1 = iref2.

* recommended access:

... iref1->comp1 ...

* this access is not recommended:

... iref2->i1~comp1 ...
... iref3->i2~comp2 ...
Implementing Nested Interfaces in Classes
When a nested interface is implemented in a class, all associated interfaces are implemented in the class at the
same level irrespective of their nesting hierarchy and the class must implement all methods only once.
INTERFACE i1.
DATA comp1.
METHODS meth1.
ENDINTERFACE.

INTERFACE i2.
DATA comp2.
INTERFACES i1.
ENDINTERFACE.

INTERFACE i3.
DATA comp3.
INTERFACES i2.
ENDINTERFACE.

PUBLIC SECTION.
INTERFACES i3.
ENDCLASS.

METHOD i1~meth.
...
ENDMETHOD.
ENDCLASS.

DATA cref TYPE REF TO class.
DATA iref1 TYPE REF TO i1.

iref1 = iref2 = iref3 = cref.

* recommended access:


* this access is not recommended:

... cref->i1~comp1 ...

... iref3->i1~comp1 ...
... iref3->i2~comp2 ...
... iref2->i1~comp1 ...
You can always assign reference variables using up cast. Class reference variables for classes that implement a
compound interface can be assigned to all interface references that are typed with reference to an associated
interface component. In the class, the interface reference variables know only the components of their respective
interfaces. The same applies for assignments between interface reference variables. It is possible to access
components using the interface component selector, but this is not recommended. Compound expressions such
as cref->i3~i2~comp2 or cref->i3~i2~i3~comp3 are not possible.
6 Events
Events are generally characterized by occurring at a particular point in time. When an event is triggered, other
actions can be executed as a consequence. Examples of when events can be triggered include changes in the
status of an object, such as the cancellation of a posting or the generation of a new account (object). Other
interested objects are informed of these situations by events.
In contrast to other object-oriented programming languages, the event concept in ABAP Objects is an integral
component of the language itself. Using the statement EVENTS, objects can contain declared events as a part of
their interface, and trigger them using RAISE EVENT. Using the addition FOR EVENT of the statement METHODS,
other objects can also contain event handlers and therefore are able to react appropriately to an event. An object
that triggers an event does not make any assumptions about which, and how many objects will handle the event,
and if so, how this will be done. This means that the event concept represents a separation between the caller and
the handler that must be clearly differentiated from a concept that uses callback routines, in which only one object
reacts in a predefined manner. During a normal method call, a method can be called by any number of users,
while the triggering of an event can lead to any number of event handlers being called. The link between the
trigger and the handler is made at runtime. In a normal method call, the caller clearly defines which method he/she
wants to call, and the corresponding method must exist. In events, the handler determines to which events it will
react, and a handler does not have to be registered for every event.
An event handler in an object statically determines which events of which classes the object can handle. Before an
object can react to relevant events, its event handlers must be dynamically registered for the events of other
objects using the statement SET HANDLER. One object can be registered for the events of several other objects at
the same time. This registration can be revoked at any time by users of the object or by the object itself. All
registered event handlers are currently executed synchronously. This means that they are executed after the
statement RAISE EVENT and before the next statement. This also applies for events that are triggered during the
handling of other events.
If an object triggers an event during the execution of a method, each appropriate registered event handler method
is called, and the triggering method can transfer parameters. If several event handlers are registered for one
event, these are called in the sequence in which they were registered.
Event handlers can also be called directly. There can be two reasons for this: Either you want an event handler to
handle an event without being registered, or to simulate the triggering of an event.
Events can have output parameters, which are defined in the same way as those of methods. An event handler
can transfer these same output parameters as input parameters, whereby the transfer is always a value. In
addition, there is always an implicit parameter called sender that contains a reference to the triggering object, via
which the event handler gains access to this object.
7 Friends - Friendship Between Classes
There is normally a strict division between external (PUBLIC) and internal (PROTECTED and PRIVATE) classes. A
user can only access the public components of a class. This allows you to change the internal implementation of a
class without invalidating its users.
In rare cases, however, classes have to work so closely together that they require access to each others' invisible
components. The concept of friendship between classes has been developed so that these components do not
need to be made available to all users at the same time.
Friends
A class can grant friendship to other classes and interfaces (and thus to all classes that implement this interface).
To create this relationship, use the FRIENDS additions of the CLASS ... DEFINITION statement that includes all
classes and interfaces to which you want to grant friendship. These friends are granted access to all components
of the class offering the friendship, regardless of their visibility section or the addition READ-ONLY and can always
create instances of this class regardless of the addition CREATE of the statement CLASS.
Friendship is unilateral
Friendship is a unilateral principle. A class that grants friendship is not automatically a friend of its friends. If the
class that grants friendship wants to access the private or protected components of its friend, the latter must grant
friendship explicitly.
Inheritance, Interfaces, and Friendship
Subclasses of friends and interfaces that are assigned a friend as a component interface also become friends. For
this reason, you should be extremely careful when defining a friendship. The higher a friend is in the inheritance
tree, the greater the number of subclasses that can access all of the components of the class granting friendship.
A class that grants friendship to the root class object gains all of the ABAP Objects classes as friends and
therefore has no privacy whatsoever. Conversely, it is relatively safe to grant friendship to a final class since this
class alone is specified as a friend.
Friendship granted is not inherited, in contrast to the friend attribute. A friend of a superclass is, therefore, not
automatically a friend of its subclasses.
The FRIENDS Additions
The statement CLASS ... DEFINITION has three FRIENDS additions:
... FRIENDS cif1 ... cifn

This addition can be specified when defining any local class of a program. Friendship can be granted to all
classes or interfaces of the same program and to the classes and interfaces in the class library. Note, in
particular, that the local classes of a class pool can grant friendship to the global class of that class pool.
... GLOBAL FRIENDS cif1 ... cifn

This addition can only be used with global classes and is created by the Class Builder during generation.
Friendship can be granted to all other global classes and interfaces.
... LOCAL FRIENDS cif1 ... cifn

This addition is not specified when the class is declared, but instead defines its own statement. In a class
pool, the global class can use this statement to grant friendship to the local classes and interfaces of its
own class pool. While the Class Builder generates the CLASS statement for the actual class declaration, the
statement

CLASS ... DEFINITION LOCAL FRIENDS cif1 ... cifn.

is entered directly in the include program for defining local classes and interfaces.
8 Objects
Objects are instances of classes. There can be any number of objects or instances in a class. Each object has a
unique identity and its own attributes.
As standard, all objects have the same priority in the data area of an internal session. This means that objects can
only be accessed from within an internal session.
For transaction-independent objects, shared objects are available, which can be accessed by all programs of an
application server at the same time.
Object Services are available for handling persistent objects in the database. These link the attributes of objects
with the content of database tables and can execute object-oriented transactions.
Creating Objects
If you want to create an object, you need an object reference variable that can point to the required class:
Having declared a class reference variable obj for a class class, you can create an object of that class
using the statement CREATE OBJECT obj. This statement creates an instance of the class class and the
reference variable obj contains a reference to this object.
Having declared a class reference variable obj for a superclass of the class class or an interface
reference variable obj for an interface implemented by the class class, you can use the TYPE class
addition of the CREATE OBJECT obj statement to create an instance of the class class.
Access to Instance Components
A program can access the visible instance components of an object only through references in reference
variables. For the syntax, see Accessing Components of Classes.
Lifetime of Objects
An object is kept alive for as long as it is used in the internal session (Heap). The system will continue use the
object provided that at least one Heapreference points to the object, an instance attribute or part of the instance
attribute or provided that at least one method of the object is registered as an event handler. Field symbols to
which an instance attribute or part of an instance attribute is assigned still work in the same way as data
references.
As soon as an object has no more references and none of its methods is registered as an event handler, it can be
deleted by the Garbage Collector). This releases the identity of the object to be taken by a new object.
Note
Alongside these regular references, weak references represented by objects exist that do not keep an object alive.
8.1 Object References
Object references are used as pointer objects. Object references (the content of object reference variables) are
the only way to access the components of objects in an ABAP program. You can use references to access
attributes and methods, but not events.
Object Reference Variables
Object reference variables contain object references. An object reference variable oref is either initial or contains
a reference to an existing object. In the latter case, the logical expression oref IS BOUND is true. An object
reference variable that points to an object contains the 'address' of the object. Objects and their components can
only be addressed through object references.
Reference variables are data objects with a deep data type. A reference variable can be defined as the smallest
indivisible unit of complex data objects such as structures and internal tables. When handling reference variables
or complex data objects that contain reference variables, note the special features that apply for deep types.
Static Type of Object Reference Variables
Object reference variables can be created either as class reference variables or interface reference variables.
Class Reference Variables
A reference variable with the static type of a class is called a class reference variable. Class reference
variables are defined by the addition TYPE REF TO class of the TYPES statement or the DATA statement. In
this case, class is a class known at the point of declaration.
A class reference variable cref enables the user to use the form cref->comp to access all of the visible
components comp of the object to which the object reference points, which usually means all public
components of the class.
Interface Reference Variables
A reference variable with the static type of an interface is called an interface reference variable. Interface
reference variables are defined by the addition TYPE REF TO intf of the TYPES statement or the DATA
statement. In this case, intf is an interface known at the point of declaration.
An interface reference iref enables the user to use iref->icomp to access all of the visible interface
components icomp of the object to which the reference points. Interface components are those components
of an object that are declared by implementing the interface in the class.
As well as in declarations, you can also use the TYPE REF TO ... addition in all other statements in which type
specifications are possible, for example, to specify the types of interface parameters in procedures.
Special Object Reference Variables
Within a class there are two specific references, the self-reference me and the pseudo reference super.
The self-reference me is used to explicitly address an object's components. In the instance methods of a
class, me is a predefined local reference variable with the same type as the class in which the instance
method is implemented, which points to its own instance. It can be specified when addressing its own
component but does not have to be. It can also be assigned to other reference variables or passed to
methods.
The pseudo reference super is used to call the hidden method in a redefined instance method during
inheritance. The pseudo reference reference is not a genuine reference because an instance of a subclass
cannot have an associated superclass instance, and hence cannot have a reference variable. The pseudo
reference super is the syntactical expression for a method call in a superclass.
Initializes Object Reference Variables
Like other variables, object reference variables are also initialized using the statement CLEAR. The initial value of
an object reference variable is a reference that does not point to any object.
Assigning Object References Using Up Cast
Object references can be assigned between object reference variables (using the MOVE statement). This means
that the references in several reference variables can point to the same object (sharing). If you make assignments
between reference variables, the dynamic type of the source variable must be compatible with the static type of
the target variable. The dynamic type is the class of the object to which the reference in a reference variable
points. The static type is the type (class or interface) with which the reference variable has been typed. The static
type of the target variable must always be more general than the dynamic type of the source variable.
The syntax check in the program can only compare the static type of the source variable with the static type of the
target variable. If reference variables are assigned using the MOVE statement or the assignment operator (=), the
system performs this comparison and assignments can only be made that fulfill the above requirements for static
types (up cast). The same applies when passing parameters to procedures. Assignments are always possible if
the static type of the target variable can address the same number of components as the static type of the source
variable or fewer components.
If cref1 and cref2 are class reference variables, and iref1 and iref2 are interface reference variables, the
following assignments can be checked statically:
cref1 = cref2
Both class reference variables must refer to the same class, or the class of cref1 is a superclass of the
class of cref2. The class of cref1 can therefore always be object, because object is the superclass for
all classes in ABAP Objects.
iref1 = iref2
Both interface reference variables must refer to the same interface, or the interface of iref2 must be a
nested interface that contains interface of iref1 as a component.
iref1 = cref1
The class of the class reference variable cref1 or one of its superclasses must implement the interface of
the interface reference variable iref1. The implementation can be performed directly or using a nested
interface that contains the interface of iref1 as a component.
cref1 = iref1
The class of cref1 must be object, that is, the reference variable cref1 must have the type REF TO
object.
object is a predefined empty class and the root node for all inheritance trees in ABAP Objects. This class has no
components and is the generic type of all object reference variables. Reference variables with the type object can
be used as containers for passing references. They cannot be used for static access to objects. Dynamic access is
possible.
Assigning Object References Using Down Cast
If a static type check is not possible, or whenever you want the type check to take place at runtime, you need to
use the statement MOVE ... ?TO or the casting operator (?=). When you use either MOVE ... ?TO or ?=, there is
no static type check. Instead, the system checks at runtime whether the object reference in the source variable
points to an object to which the object reference in the target variable may also point (down cast).The dynamic
type of the source variable is compared with the static type of the target variable. If assignment is possible, the
system assigns the reference, otherwise, it raises the handleable exception CX_SY_MOVE_CAST_ERROR.
The syntax requires you to use a down cast in all cases that are not listed above for static type checks.
Example
cref1 ?= iref1
Assigning an interface reference variable to a class reference variable. For the assignment to be
successful, the object to which iref1 points must belong to the same class as the type of the class
reference variable cref1 or to an appropriate subclass.
Object References as Actual Parameters
You can pass object references as actual parameters to procedures (methods, function modules, and subroutines)
by specifying object reference variables. As far as typed formal parameters are concerned, note that you may only
pass actual parameters of exactly the same type if the formal parameter can be changed in the procedure. This
applies also to EXPORTING and CHANGING parameters of function modules and methods, parameters in subroutines
passed by reference and CHANGING parameters in subroutines passed by value.
Passing actual parameters to formal parameters that corresponds to an up cast, such as passing a class reference
variable to a formal parameter which is typed with reference to an interface of the class or one of its superclasses,
is not possible if the parameter can be changed in the procedure.
The reason is that a reference could be assigned to the actual parameter in the procedure which is incompatible
with its static type, such as a reference to any other class that implements the same interface or a reference to a
subclass in another path of the inheritance tree.
Assigning Object References to Field symbols
When you assign object references to typed field symbols, the same applies as when you pass a reference to
typed formal parameters: The types must be identical. Otherwise, incompatibilities between dynamic and static
types may occur. For example, if you assign two class reference variables of different classes implementing the
same interface one after the other to the same field symbol, an inconsistent state results.
8.2 Accessing Class Components
When accessing class components, there is a difference between access from inside and outside the same class.
When a component is accessed from inside, that is within a method of the same class, the name of the component
is sufficient. When a component is accessed from outside, the object for instance components and the class for
static components must be specified with an object component selector or class component selector. There are
static and dynamic variants.
For static access, object reference variables can only be used to access components that are known to the
reference variable. These are the components that are available in the static type of the reference variable (class
or interface). Class reference variables that are typed with reference to a superclass but point to subclasses know
only the superclass components. Interface references know only interface components.
With dynamic access, the dynamic type is used to get the component for class reference variables. This is the type
of the object to which the reference refers, and not the type used for typing the reference. For interface reference
variables the static type is also used for dynamic access, that is, the type that was used to type the reference.
This means that reference variables that have been typed with reference to a superclass. They point to subclasses
that can be used to dynamically access any component of the subclass for which dynamic access is possible. In
particular, reference variables of the type REF TO OBJECT can be used to dynamically access components.
However, it is not possible to use interface reference variables to access class-specific components dynamically;
only the associated interface components can be accessed. It is not possible to access class-specific components
using interface reference variables, because, when accessing with interface reference variables, the implicit use of
the intf~ prefix is always required.
Static Access
The following syntax applies (oref is an object reference variable):

Accessing an instance attribute attr: oref->attr
Calling an instance method meth: oref->meth( ... )
In addition to reference variables, the class name can be used for accessing static components :
Accessing a static attribute attr: class=>attr
Calling a static method meth: class=>meth( ... )
In this context, it is important to note that the properties of instance methods behave like static components.
Therefore, in a LIKE addition, the class component selector or reference variables can be used to refer to visible
attributes of a class, without first creating an object.
In addition to specifying the name, accessing the components of a class is also possible using the self-reference
me:
Accessing attributes within the class attr: me->attr
Calling a method within the same class meth: me->meth( ... )
Self-reference allows an object to pass a reference to itself to other objects. In addition, attributes within an
object can be accessed in methods which are obscured by the local attributes of the method.
Within a redefined method of a subclass, the pseudo reference super can be used to access the obscured method
in one of the superclasses:
Calling an obscured method meth: super->meth( ... )
Within the instance constructor of a subclass, the pseudo reference super must be used to call the
instance constructor of the direct superclass:
Calling the constructor of the direct superclass:
super->constructor( ... )
As a specific method for accessing attributes, the attributes for key access to internal tables can be used if they
contain reference variables.
Dynamic Access
Der dynamische Zugriff auf Komponenten von Klassen ist fr Attribute (Dynamic Access) und fr Methodenaufrufe
(Dynamic Invoke) mglich.
Accessing Attributes Dynamically
Dynamic access to attributes is possible using the dynamic ASSIGN to field symbols.
The following variants can be used (oref is an object reference variable):

Fully dynamic specification:

ASSIGN (f) TO <fs>.
Partly dynamic specification for instance attributes:

ASSIGN oref->(f) TO <fs>.
Partly dynamic specification for static attributes:

ASSIGN (f1)=>(f2) TO <fs>.
The contents of the fields f, f1 and f2 are interpreted as descriptors of attributes. In a completely dynamic case,
f can, for example, have the content 'oref->attr'. In the case of the partly dynamic specification for instance
attributes, f only describes the attribute (which itself can in turn describe another attribute). f1 and f2 can be class
names and static attributes.
Dynamic Method Calls
The following syntax applies (oref is an object reference variable):

Calling an instance method meth:

CALL METHOD oref->(f)
Calling a static method meth:

CALL METHOD class=>(f)
CALL METHOD (c)=>meth
CALL METHOD (c)=>(f)
Calling a method within the same class meth:

CALL METHOD (f)
CALL METHOD me->(f)
f and c are fields containing the name of the method meth or class class.
In the case of dynamic method calls, the actual parameter can be passed dynamically to specific internal tables,
similarly to calling function modules.
8.3 Object References in Internal Tables
If the line type of an internal table contains object reference variables in the form of the component comp, the
attributes attr of the object (to which each reference of the line points), can be used as key values for reading,
sorting, and changing lines in tables. This option can be used 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 a table contains unstructured lines with the type of a object reference variable, the attributes of the object, to
which a line points, can be addressed using table_line->attr .
8.4 Weak References
An object in the system class CL_ABAP_WEAK_REFERENCE represents a weak reference to an object in a
class. Unlike regular object references, a weak reference is ignored during execution of the garbage collector. This
means that a weak reference does not prevent the referenced object from being deleted when the garbage
collector is executed.
A weak reference to an existing object is created by passing an object reference to the instance constructor of
CL_ABAP_WEAK_REFERENCE. You can then use the functional method GET to retrieve the reference
afterwards. If the object was deleted in the meantime, the return value is initial.
Note
A different type of reference retains objects until the available memory becomes limited. The class
CL_ABAP_SOFT_REFERENCE is available for these soft references, but this class is currently still implemented
in the same way as class CL_ABAP_WEAK_REFERENCE.
9 Statements in ABAP Objects
The statements in ABAP Objects can be classified as follows:
Statements for defining classes and interfaces
These statements define classes and interfaces and their components. They can be used for local and
global classes or interfaces.
Statements for implementing methods

These statements implement the functionality of classes in methods.
Statements in class- and interface pools
In addition to the statements for defining global classes, statements for local declaration and
implementation can also be used in class pools. In interface pools it is only possible to declare a type group
in addition to the definition of the global interface.
A language clean-up has been carried out in ABAP Objects. The stricter ABAP syntax applies to all statements in
ABAP Objects.

9.1 Statements for Defining Classes and Interfaces
The following statements define classes and interfaces and their components. You can use them in any ABAP
program in which class and interface can be defined.
Statements for Defining Classes
Defining the Declaration Part
CLASS ... DEFINITION ...
...
ENDCLASS ...
Defining the Implementation Part
CLASS ... IMPLEMENTATION ...
...
ENDCLASS ...
Statements for Defining Class Components
Statements in the Declaration Part
PUBLIC SECTION.
PROTECTED SECTION.
PRIVATE SECTION.

TYPES ...

INTERFACES ...
ALIASES ...

CONSTANTS ...

CLASS-DATA ...
DATA ...

CLASS-METHODS ...
METHODS ...

CLASS-EVENTS ...
EVENTS ...
Statements in the Implementation Part
METHOD ...
...
ENDMETHOD.
Statements for Defining Interfaces
Declaring the Interface
INTERFACE ...
...
ENDINTERFACE ...
Statements for Declaring Interface Components
In interfaces, you can use the same statements to declare interface components as those used in the declaration
part of classes.
Note
In the declaration part of a class or in interface, you declare its components, that is, its attributes, methods, and
events. You can declare local data types using the TYPES statement. You can also declare alias names for the
components of implemented interfaces using the ALIASES statement. In a class, all declarations must belong to
one of the four visibility sections introduced by the relevant statement.
The implementation part of a class only contains method implementations in METHOD - ENDMETHOD blocks. In a
method, you can only use the statements for method implementations.
No statements other than those listed above are necessary for defining classes or interfaces. Consequently, no
other statements are allowed between CLASS and ENDCLASS or INTERFACE - ENDINTERFACE except within
methods.
The stricter syntax in ABAP Objects applies to all statements for defining classes and interfaces.
Statements for implementing methods
Methods are used to implement the functionality of classes (between METHOD - ENDMETHOD).
The statements allowed in methods basically include the entire ABAP language scope, which is allowed in all
procedures, i.e. also for function modules and subroutines. However, please note that all statements in methods
are subject to the stricter syntax of ABAP Objects.
9.3 Statements in Class and Interface Pools
Class pools and interface pools are the ABAP programs in the class library. They are defined using Class Builder
tool in ABAP Workbench and are used as a repository for global classes and interfaces.
A program of program type class pool is launched using the statement CLASS-POOL.
A program of program type interface pool is launched using the statement INTERFACE-POOL.
These statements are generated by Class Builder.
Each class pool or interface pool can only contain a single global class or a single global interface. These classes
or interfaces are declared using the following statements:
CLASS ... PUBLIC. ... ENDCLASS.
INTERFACE ... PUBLIC. ... ENDINTERFACE.
Class Builder uses the properties entered here to generate these statements.
Further Statements in Class Pools
As well as the declaration of the global class, a class pool can only contain the following statements:
Declaration of local data types using the statement TYPES. These data types can be used by the global
class in the private visibility section and in the implementation part.
Declaration of local constants using the statement CONSTANTS. These data types can be used by the global
class in the private visibility section and in the implementation part.
Declaration of local interfaces using the statements INTERFACE ... ENDINTERFACE. These data types can be
used by the global class in the private visibility section and in the implementation part.
Declaration and implementation of local classes using the statements CLASS ... ENDCLASS. These data types
can be used by the global class in the private visibility section and in the implementation part.
Definition of macros using DEFINE ...END-OF-DEFINITION. These macros can be used by the global class in
the implementation part.
Locally defined types, classes, and interfaces in class pools can be used in the following ways:
Only the methods of the global class access the local declarations and implementations in the program.
These provide auxiliary methods, for example, which should not be displayed in the interface of the global
class. This is the most common scenario. Any changes made to local declarations in the program do not
influence the interface of the global class.
As well as the methods in the global class, declarations in the private visibility section of the class also
reference local declarations in the program. This is a more unusual scenario, in which changes made to the
local declarations influence the interface of the global class, and subclasses and friends of the global class
are recompiled before the program is executed again.
Further Statements in Interface Pools
In addition to the declaration of the global interface, an interface pool cannot contain any of its own declarations or
implementations.
Program Organization
Like any other ABAP program, class pools and interface pools consist of a global declaration part for declarations
and an implementation part for implementations (or procedures).
This means that the global declaration part of a class pool can contain the declarations of local data types,
local interfaces, and local classes, as well as the actual declaration part of the global class. The
implementation part of a class pool can contain the implementation parts of local classes, as well as the
implementation part of the global class.
The global declaration part of an interface pool can only contain the declaration of type groups and the
declaration of the global interface. The implementation part of an interface pool is always empty.
The Class Builder organizes the various declarations and implementations of a class pool or interface pool in
include programs. The developer cannot usually view the names of these programs. A Class Builder function
allows you to open the associated include programs in ABAP Editor and edit them. Include programs exist for:
Each visibility section in the declaration part of the global class
Each implementation of a method of the global class
Local declarations and implementations
Test Classes for ABAP Unit
To edit the global class, Class Builder provides you with both editing functions for the individual include programs
and a source code-based mode in which you can display all the include programs as a single program and edit
them.
Restrictions
Apart from the statements listed above, statements other than CLASS - ENDCLASS and INTERFACE -
ENDINTERFACE are neither required in class pools and interface pools nor are they permitted. The stricter syntax of
ABAP Objects applies to all statements permitted.
The following restrictions are particularly important:
No processing blocks except methods
Neither event blocks such as START-OF-SELECTION, AT SELECTION-SCREEN,GET, or AT LINE-SELECTION
nor dialog modules (defined by MODULE - ENDMODULE) are permitted. This means that runtime environment
events cannot be processed. ABAP Objects has its own event concept. Neither function modules nor
subroutines can be defined using FUNCTION - ENDFUNCTION or FORM - ENDFORM. The methods of a class
pool can still call external function modules and subroutines, as well as methods.
No interface work areas to other programs
The statements TABLES and NODES and the addition COMMON PART of the DATA statement are not possible.
This means that class pools and interface pools do not support any global data areas across programs
within a single internal mode.
No dedicated screens
Screen processing as implemented in other ABAP programs is not possible. No screens can be defined in
a class pool or interface pool. If you want to use classic screens, including selection screens, we
recommend that you encapsulate them in function groups. We recommend that you use other suitable
output media instead of classic lists. For table list output, use the classes of SAP List Viewer (ALV), such as
CL_SALV_TABLE. For simple text output, we recommend browser control wrappers such as dynamic
documents or text edit control wrappers.
No processing of extracts
Extract data sets cannot be edited in global classes since the defining statement FIELD-GROUPS is not
permitted in class or interface pools.
9.4 ABAP Objects - Keywords
The following list displays the keywords specially introduced for ABAP objects.

9.5 Replacements for Obsolete Language Constructs in ABAP Objects
The ABAP language has been cleaned up in ABAP Objects. As part of this language clean-up, stricter syntax
checks are performed for constructs that were previously allowed, or obsolete statements are no longer allowed at
all. The stricter syntax checks usually result in syntax which we also recommend for use outside of ABAP Objects
but where the old versions cannot be forbidden for compatibility reasons.
ALIASES Declares an alias name
CALL METHOD
Calls a method dynamically
CLASS ... ENDCLASS
Defines a class
CLASS-DATA Declares a static attribute
CLASS-EVENTS Declares a static event
CLASS-METHODS
Declares a static method
CREATE OBJECT
Creates an object.
EVENTS Declares an instance event
INTERFACE ... ENDINTERFACE Defines an interface
INTERFACES
Includes an interface
METHOD ... ENDMETHOD
Defines a method
METHODS Declares an instance method
PRIVATE SECTION Introduces the package visibility section
PROTECTED SECTION
Introduces the protected visibility section
PUBLIC SECTION
Introduces the public visibility section
RAISE EVENT Triggers an event
SET HANDLER Registers an event
The syntax revisions are listed in detail in the documentation of the languaghe elements and also in the list of
obsolete language elements.
The syntax revisions apply to all statements in ABAP Objects.
10 Examples for ABAP Objects
10.1 ABAP Objects, Overview
This example demonstrates objects, object references, inheritance, interfaces, and events.
Source Code
REPORT demo_abap_objects.

*---------------------------------------------------------------------*
* Global Selection Screen
*---------------------------------------------------------------------*

SELECTION-SCREEN BEGIN OF SCREEN 100 AS WINDOW TITLE text-100.
PARAMETERS: button1 RADIOBUTTON GROUP grp,
button2 RADIOBUTTON GROUP grp,
button3 RADIOBUTTON GROUP grp,
button4 RADIOBUTTON GROUP grp.
SELECTION-SCREEN END OF SCREEN 100.

*---------------------------------------------------------------------*
* INTERFACE status
*---------------------------------------------------------------------*
* Interface definition *
*---------------------------------------------------------------------*
INTERFACE status.
METHODS write.
ENDINTERFACE.

*---------------------------------------------------------------------*
* CLASS vessel DEFINITION
*---------------------------------------------------------------------*
* Superclass definition *
*---------------------------------------------------------------------*
CLASS vessel DEFINITION.
PUBLIC SECTION.
METHODS: constructor,
drive
IMPORTING speed_up TYPE i,
get_id
RETURNING value(id) TYPE i.
PROTECTED SECTION.
DATA: speed TYPE i,
max_speed TYPE i VALUE 100.
PRIVATE SECTION.
CLASS-DATA object_count TYPE i.
DATA id TYPE i.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS vessel IMPLEMENTATION
*---------------------------------------------------------------------*
* Superclass implementation *
*---------------------------------------------------------------------*
CLASS vessel IMPLEMENTATION.
METHOD constructor.
object_count = object_count + 1.
id = object_count.
ENDMETHOD.
METHOD drive.
speed = speed + speed_up.
IF speed > max_speed.
speed = max_speed.
ENDIF.
ENDMETHOD.
METHOD get_id.
id = me->id.
ENDMETHOD.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS ship DEFINITION
*---------------------------------------------------------------------*
* Subclass definition *
*---------------------------------------------------------------------*
CLASS ship DEFINITION INHERITING FROM vessel.
PUBLIC SECTION.
INTERFACES status.
DATA name TYPE string READ-ONLY.
METHODS: constructor
IMPORTING name TYPE string,
drive
REDEFINITION.
EVENTS emergency_call.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS ship IMPLEMENTATION
*---------------------------------------------------------------------*
* Subclass implementation *
*---------------------------------------------------------------------*
CLASS ship IMPLEMENTATION.
METHOD constructor.
super->constructor( ).
max_speed = 30.
me->name = name.
ENDMETHOD.
METHOD status~write.
DATA id TYPE c LENGTH 1.
id = me->get_id( ).
WRITE: / name, 'is vessel', id,
'and has speed', speed.
ENDMETHOD.
METHOD drive.
speed = speed + speed_up.
IF speed > max_speed.
max_speed = 0.
speed = 0.
RAISE EVENT emergency_call.
ENDIF.
ENDMETHOD.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS coast_guard DEFINITION
*---------------------------------------------------------------------*
* Event handler definition *
*---------------------------------------------------------------------*
CLASS coast_guard DEFINITION.
PUBLIC SECTION.
INTERFACES status.
METHODS receive
FOR EVENT emergency_call OF ship
IMPORTING sender.
ALIASES write FOR status~write.
PRIVATE SECTION.
DATA caller TYPE string.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS coast_guard IMPLEMENTATION
*---------------------------------------------------------------------*
* Event handler implementation *
*---------------------------------------------------------------------*
CLASS coast_guard IMPLEMENTATION.
IF caller IS INITIAL.
WRITE: / 'Coast guard received no call'.
ELSE.
WRITE: / 'Coast guard received a call from', caller.
ENDIF.
ENDMETHOD.
METHOD receive.
caller = sender->name.
write( ).
ENDMETHOD.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS main DEFINITION
*---------------------------------------------------------------------*
* Main class definition *
*---------------------------------------------------------------------*
CLASS main DEFINITION.
PUBLIC SECTION.
CLASS-METHODS: start,
objects,
inheritance,
interfaces,
events.
ENDCLASS.

*---------------------------------------------------------------------*
* CLASS main IMPLEMENTATION
*---------------------------------------------------------------------*
* Main class implementation *
*---------------------------------------------------------------------*
CLASS main IMPLEMENTATION.

METHOD start.
CALL SELECTION-SCREEN 100 STARTING AT 10 3
ENDING AT 42 7.
IF sy-subrc NE 0.
EXIT.
ELSEIF button1 = 'X'.
objects( ).
inheritance( ).
interfaces( ).
events( ).
ENDIF.
ENDMETHOD.

METHOD objects.
DATA: vessel1 TYPE REF TO vessel,
vessel2 TYPE REF TO vessel.
DATA: vessel_id TYPE i.
CREATE OBJECT: vessel1 TYPE vessel,
vessel2 TYPE vessel.
vessel1->drive( 50 ).
vessel2->drive( 80 ).
vessel_id = vessel1->get_id( ).
WRITE: / 'Vessel ID is', vessel_id.
vessel_id = vessel2->get_id( ).
WRITE: / 'Vessel ID is', vessel_id.
ENDMETHOD.

METHOD inheritance.
DATA: vessel TYPE REF TO vessel,
ship TYPE REF TO ship.
CREATE OBJECT ship TYPE ship EXPORTING name = 'Titanic'.
ship->drive( 20 ).
MOVE ship TO vessel.
vessel->drive( 10 ).
ship->status~write( ).
ENDMETHOD.

METHOD interfaces.
DATA: status_tab TYPE TABLE OF REF TO status,
status TYPE REF TO status,
ship TYPE REF TO ship,
station TYPE REF TO coast_guard.
CREATE OBJECT ship EXPORTING name = 'Titanic'.
APPEND ship TO status_tab.
CREATE OBJECT station.
APPEND station TO status_tab.
LOOP AT status_tab INTO status.
status->write( ).
ENDLOOP.
ENDMETHOD.

METHOD events.
DATA: ship TYPE REF TO ship,
station TYPE REF TO coast_guard.
CREATE OBJECT: ship EXPORTING name = 'Titanic',
station.
SET HANDLER station->receive FOR ship.
DO 5 TIMES.
ship->drive( 10 ).
ENDDO.
ENDMETHOD.

ENDCLASS.

*---------------------------------------------------------------------*
* System event START-OF-SELECTION
*---------------------------------------------------------------------*
* Triggered by the ABAP runtime environment automatically *
*---------------------------------------------------------------------*

START-OF-SELECTION.
main=>start( ).

*---------------------------------------------------------------------*
Description
The program contains a class main with a method start which is called at program start and demonstrates the
use of ABAP objects using the example of classes of water vehicles.
10.2 ABAP Objects, Classes
This example demonstrates a class for counters.
Source Code
REPORT demo_class_counter .

CLASS counter DEFINITION.
PUBLIC SECTION.
METHODS: set
IMPORTING value(set_value) TYPE i,
increment,
get
EXPORTING value(get_value) TYPE i.
PRIVATE SECTION.
DATA count TYPE i.
ENDCLASS.

CLASS counter IMPLEMENTATION.
METHOD set.
count = set_value.
ENDMETHOD.
METHOD increment.
ADD 1 TO count.
ENDMETHOD.
METHOD get.
get_value = count.
ENDMETHOD.
ENDCLASS.

DATA number TYPE i VALUE 5.
DATA cnt TYPE REF TO counter.

START-OF-SELECTION.

CREATE OBJECT cnt.

cnt->set( number ).

DO 3 TIMES.
cnt->increment( ).
ENDDO.

cnt->get( IMPORTING get_value = number ).

WRITE number.
Description
The counter class contains three public methods set, increment and get, which work with the private integer field
count. Two of the methods have input and output parameters with which they define the data interface of the
class. The field count is not visible externally.
10.3 ABAP Objects, Inheritance
This example demonstrates the specialization of a counter using inheritance.
Source Code
REPORT demo_inheritance.

PUBLIC SECTION.
METHODS: set
IMPORTING value(set_value) TYPE i,
increment,
get
EXPORTING value(get_value) TYPE i.
PROTECTED SECTION.
DATA count TYPE i.
ENDCLASS.

METHOD set.
count = set_value.
ENDMETHOD.
METHOD increment.
ADD 1 TO count.
ENDMETHOD.
METHOD get.
get_value = count.
ENDMETHOD.
ENDCLASS.

CLASS counter_ten DEFINITION INHERITING FROM counter.
PUBLIC SECTION.
METHODS increment REDEFINITION.
DATA count_ten TYPE c LENGTH 1.
ENDCLASS.

CLASS counter_ten IMPLEMENTATION.
METHOD increment.
DATA modulo TYPE i.
super->increment( ).
WRITE / count.
modulo = count MOD 10.
IF modulo = 0.
count_ten = count_ten + 1.
WRITE count_ten.
ENDIF.
ENDMETHOD.
ENDCLASS.

DATA: count TYPE REF TO counter,
number TYPE i VALUE 5.

START-OF-SELECTION.

CREATE OBJECT count TYPE counter_ten.

count->set( number ).

DO 20 TIMES.
count->increment( ).
ENDDO.
Description
The counter_ten class is derived from counter and redefines the increment method. In counter, the visibility of
the attribute count must be changed from PRIVATE to PROTECTED. In the redefined method, the nested method
with the pseudo reference super-> is called. The redefined method specializes the inherited method.
An object of the subclass is created, to which a reference variable of the superclass type points. During the
execution of the increment method, the redefined method of the subclass is executed using the superclass
reference.
10.4 ABAP Objects, Interfaces
This example demonstrates the use of interfaces.
Source Code
REPORT demo_interface.

INTERFACE status.
METHODS write.
ENDINTERFACE.

PUBLIC SECTION.
INTERFACES status.
METHODS increment.
PRIVATE SECTION.
DATA count TYPE i.
ENDCLASS.

WRITE: / 'Count in counter is', count.
ENDMETHOD.
METHOD increment.
ADD 1 TO count.
ENDMETHOD.
ENDCLASS.

CLASS bicycle DEFINITION.
PUBLIC SECTION.
INTERFACES status.
METHODS drive.
PRIVATE SECTION.
DATA speed TYPE i.
ENDCLASS.

CLASS bicycle IMPLEMENTATION.
WRITE: / 'Speed of bicycle is', speed.
ENDMETHOD.
METHOD drive.
ADD 10 TO speed.
ENDMETHOD.
ENDCLASS.

DATA: count TYPE REF TO counter,
bike TYPE REF TO bicycle,
status TYPE REF TO status,
status_tab TYPE TABLE OF REF TO status.

START-OF-SELECTION.

CREATE OBJECT: count, bike.

DO 5 TIMES.
count->increment( ).
bike->drive( ).
ENDDO.

APPEND: count TO status_tab,
bike TO status_tab.

LOOP AT status_tab INTO status.
status->write( ).
ENDLOOP.
Description
This example shows a status interface for outputting the attributes of an object and its implementation in two
different classes.
The status interface contains a write method. The counter and bicycle classes implement the interface in the
public area. Both classes must implement the interface method in the implementation part corresponding to the
required semantics.
First, two class reference variables are declared, count and bike, for the classes counter and bicycle. An
interface reference variable status and an internal table status_tab with a suitable row type for the interface
reference variable, are created for the status interface. All the reference variables begin with initial values.
Using the CREATE OBJECT statement, an object is created for each class, to which the references in count and
bike point. Using the class reference variable, the increment and drive methods are called in the respective
objects.
Through the addition of the class reference variables to the interface reference table, the rows in status_tab also
point to the two objects. Using the interface references, it is possible to call the interface method write in the
objects, but not the class methods increment or drive.
10.5 ABAP Objects, Events
The example demonstrates triggering and handling events.
Source Code
REPORT demo_abap_objects_events NO STANDARD PAGE HEADING.

************************************************************************
* Declarations
************************************************************************

INTERFACE i_vehicle.
DATA max_speed TYPE i.
EVENTS: speed_change EXPORTING value(new_speed) TYPE i.
METHODS: drive,
stop.
ENDINTERFACE.

CLASS c_ship DEFINITION.
PUBLIC SECTION.
METHODS constructor.
INTERFACES i_vehicle.
PRIVATE SECTION.
ALIASES max FOR i_vehicle~max_speed.
DATA ship_speed TYPE i.
ENDCLASS.

CLASS c_truck DEFINITION.
PUBLIC SECTION.
METHODS constructor.
INTERFACES i_vehicle.
PRIVATE SECTION.
ALIASES max FOR i_vehicle~max_speed.
DATA truck_speed TYPE i.
ENDCLASS.

CLASS status DEFINITION.
PUBLIC SECTION.
CLASS-EVENTS button_clicked EXPORTING value(fcode) TYPE sy-ucomm.
CLASS-METHODS: class_constructor,
user_action.
ENDCLASS.

CLASS c_list DEFINITION.
PUBLIC SECTION.
METHODS: fcode_handler FOR EVENT button_clicked OF status
IMPORTING fcode,
list_change FOR EVENT speed_change OF i_vehicle
IMPORTING new_speed,
list_output.
PRIVATE SECTION.
DATA: id TYPE i,
ref_ship TYPE REF TO c_ship,
ref_truck TYPE REF TO c_truck,
BEGIN OF line,
id TYPE i,
flag(1) TYPE c,
iref TYPE REF TO i_vehicle,
speed TYPE i,
END OF line,
list LIKE SORTED TABLE OF line WITH UNIQUE KEY id.
ENDCLASS.

DATA list TYPE REF TO c_list.

************************************************************************
* Implementations
************************************************************************

CLASS c_ship IMPLEMENTATION.
METHOD constructor.
max = 30.
ENDMETHOD.
METHOD i_vehicle~drive.
CHECK ship_speed < max.
ship_speed = ship_speed + 10.
RAISE EVENT i_vehicle~speed_change
EXPORTING new_speed = ship_speed.
ENDMETHOD.
METHOD i_vehicle~stop.
CHECK ship_speed > 0.
ship_speed = 0.
EXPORTING new_speed = ship_speed.
ENDMETHOD.
ENDCLASS.

CLASS c_truck IMPLEMENTATION.
METHOD constructor.
max = 150.
ENDMETHOD.
METHOD i_vehicle~drive.
CHECK truck_speed < max.
truck_speed = truck_speed + 50.
EXPORTING new_speed = truck_speed.
ENDMETHOD.
METHOD i_vehicle~stop.
CHECK truck_speed > 0.
truck_speed = 0.
EXPORTING new_speed = truck_speed.
ENDMETHOD.
ENDCLASS.

CLASS status IMPLEMENTATION.
SET PF-STATUS 'VEHICLE'.
WRITE 'Click a button!'.
ENDMETHOD.
METHOD user_action.
RAISE EVENT button_clicked EXPORTING fcode = sy-ucomm.
ENDMETHOD.
ENDCLASS.

CLASS c_list IMPLEMENTATION.
METHOD fcode_handler.
CLEAR line.
CASE fcode.
WHEN 'CREA_SHIP'.
id = id + 1.
CREATE OBJECT ref_ship.
line-id = id.
line-flag = 'C'.
line-iref = ref_ship.
APPEND line TO list.
WHEN 'CREA_TRUCK'.
id = id + 1.
CREATE OBJECT ref_truck.
line-id = id.
line-flag = 'T'.
line-iref = ref_truck.
APPEND line TO list.
WHEN 'DRIVE'.
CHECK sy-lilli > 0.
READ TABLE list INDEX sy-lilli INTO line.
line-iref->drive( ).
WHEN 'STOP'.
LOOP AT list INTO line.
line-iref->stop( ).
ENDLOOP.
WHEN 'CANCEL'.
LEAVE PROGRAM.
ENDCASE.
list_output( ).
ENDMETHOD.
METHOD list_change.
line-speed = new_speed.
MODIFY TABLE list FROM line.
ENDMETHOD.
METHOD list_output.
sy-lsind = 0.
SET TITLEBAR 'TIT'.
LOOP AT list INTO line.
IF line-flag = 'C'.
WRITE / icon_ws_ship AS ICON.
ELSEIF line-flag = 'T'.
WRITE / icon_ws_truck AS ICON .
ENDIF.
WRITE: 'Speed = ', line-speed.
ENDLOOP.
ENDMETHOD.
ENDCLASS.

************************************************************************
* Program events
************************************************************************

START-OF-SELECTION.
CREATE OBJECT list.
SET HANDLER: list->fcode_handler,
list->list_change FOR ALL INSTANCES.

AT USER-COMMAND.
status=>user_action( ).
Description
The user actions on a classic list trigger events in ABAP objects. The list and its data are implemented in the class
c_list. There is a class status for processing user actions. It triggers an event button_clicked in the AT USER-
COMMAND event. The event is handled in the class c_list. The class c_list contains an object of the class c_ship
or c_truck for each line of the list. Both of these classes implement the interface i_vehicle. Whenever the speed
of one of these objects changes, the event speed_change is triggered. The class c_list reacts to this and
updates the list.
10.6 ABAP Objects, OO Transaction
This example demonstrates the linking of a transaction code with the method of a local class.
Source Code
*&---------------------------------------------------------------------*
*& Subroutine pool DEMO_OO_TRANSACTION *
*& *
*&---------------------------------------------------------------------*

PROGRAM demo_oo_transaction.

*

CLASS demo_class DEFINITION.
PUBLIC SECTION.
METHODS instance_method.
ENDCLASS.

*

CLASS demo_class IMPLEMENTATION.
METHOD instance_method.
MESSAGE 'Instance method in local class' TYPE 'I'.
ENDMETHOD.
ENDCLASS.
Description
The program DEMO_OO_TRANSACTION is a subroutine pool that does not contain any subroutines. Instead, the
program contains the definition of the local class demo_class, with which the transaction code
DEMO_OO_METHOD is linked. When the transaction is called, the program is loaded, one instance of the class is
created, and the method is called.


ABAP Objects Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Objects Overview

Uploaded by

Copyright:

Available Formats

ABAP Objects - Overview

You might also like