BC ABAP Programming PHẦN 10 pptx

BC - ABAP Programming SAP AG
Inheritance
1380 December 1999
Inheritance
Inheritance allows you to derive a new class from an existing class. You do this using the
INHERITING FROM addition in the
CLASS <subclass> DEFINITION INHERITING FROM <superclass>.
statement. The new class <subclass> inherits all of the components of the existing class
<superclass>. The new class is called the subclass of the class from which it is derived. The
original class is called the superclass of the new class.
If you do not add any new declarations to the subclass, it contains the same components as the
superclass. However, only the
public and protected components of the superclass are visible in
the subclass. Although the private components of the superclass exist in the subclass, they are
not visible. You can declare private components in a subclass that have the same names as
private components of the superclass. Each class works with its own private components.
Methods that a subclass inherits from a superclass use the private attributes of the superclass,
and not any private components of the subclass with the same names.
If the superclass does not have a private visibility section, the subclass is an exact replica of the
superclass. However, you can add new components to the subclass. This allows you to turn the
subclass into a specialized version of the superclass. If a subclass is itself the superclass of
further classes, you introduce a new level of specialization.
A class can have more than one direct subclass, but it may only have one direct superclass.
This is called
single inheritance. When subclasses inherit from superclasses and the superclass
is itself the subclass of another class, all of the classes involved form an inheritance tree, whose
degree of specialization increases with each new hierarchical level you add. Conversely, the
classes become more generalized until you reach the root node of the inheritance tree. The root
node of all inheritance trees in ABAP Objects is the predefined empty class OBJECT. This is the
most generalized class possible, since it contains neither attributes nor methods. When you
define a new class, you do not have to specify it explicitly as the superclass - the relationship is

always implicitly defined. Within an inheritance tree, two adjacent nodes are the direct
superclass or direct subclass of one another. Other related nodes are referred to as superclasses
and subclasses. The component declarations in a subclass are distributed across all levels of
the inheritance tree.
Redefining Methods
All subclasses contain the components of all classes between themselves and the root node in
an inheritance tree. The visibility of a component cannot be changed. However, you can use the
REDEFINITION addition in the METHODS statement to redefine an inherited public or protected
instance method in a subclass and make its function more specialized. When you redefine a
method, you cannot change its interface. The method retains the same name and interface, but
has a new implementation.
The method declaration and implementation in the superclass is not affected when you redefine
the method in a subclass. The implementation of the redefinition in the subclass obscures the
original implementation in the superclass.
Any reference that points to an object of the subclass uses the redefined method, even if the
reference was defined with reference to the superclass. This particularly applies to the self-
reference ME->. If, for example, a superclass method M1 contains a call CALL METHOD [ME-
>]M2, and M2 is redefined in a subclass, calling M1 from an instance of the subclass will cause
SAP AG BC - ABAP Programming
Inheritance
December 1999 1381
the original method M2 to be called, and calling M1 from an instance of the subclass will cause
the redefined method M2 to be called.
Within a redefine method, you can use the pseudoreference SUPER-> to access the obscured
method. This enables you to use the existing function of the method in the superclass without
having to recode it in the subclass.
Abstract and Final Methods and Classes
The ABSTRACT and FINAL additions to the METHODS and CLASS statements allow you to
define abstract and final methods or classes.
An abstract method is defined in an abstract class and cannot be implemented in that class.

Instead, it is implemented in a subclass of the class. Abstract classes cannot be instantiated.
A final method cannot be redefined in a subclass. Final classes cannot have subclasses. They
conclude an inheritance tree.
References to Subclasses and Polymorphism
Reference variables defined with reference to a superclass or an interface defined with reference
to it can also contain references to any of its subclasses. Since subclasses contain all of the
components of all of their superclasses, and given that the interfaces of methods cannot be
changed, a reference variable defined with reference to a superclass or an interface implemented
by a superclass can contain references to instances of any of its subclasses. In particular, you
can define the target variable with reference to the generic class OBJECT.
When you create an object using the CREATE OBJECT statement and a reference variable
typed with reference to a subclass, you can use the TYPE addition to create an instance of a
subclass, to which the reference in the reference variable will then point.
A static user can use a reference variable to address the components visible to it in the
superclass to which the reference variable refers. However, it cannot address any specialization
implemented in the subclass. If you use a dynamic method call, you can address all components
of the class.
If you redefine an instance method in one or more subclasses, you can use a single reference
variable to call different implementations of the method, depending on the position in the
inheritance tree at which the referenced object occurs. This concept that different classes can
have the same interface and therefore be addressed using reference variables with a single type
is called polymorphism.
Namespace for Components
Subclasses contain all of the components of all of their superclasses within the inheritance tree.
Of these components, only the public and protected ones are visible. All public and protected
components within an inheritance tree belong to the same namespace, and consequently must
have unique names. The names of private components, on the other hand, must only be unique
within their class.
When you redefine methods, the new implementation of the method obscures the method of the
superclass with the same name. However, the new definition replaces the previous method

implementation, so the name is still unique. You can use the pseudoreference SUPER-> to
access a method definition in a superclass that has been obscured by a redefinition in a
subclass.
BC - ABAP Programming SAP AG
Inheritance
1382 December 1999
Inheritance and Static Attributes
Like all components, static attributes only exist once in each inheritance tree. A subclass can
access the public and protected static attributes of all of its superclasses. Conversely, a
superclass shares its public and protected static attributes with all of its subclasses. In terms of
inheritance, static attributes are not assigned to a single class, but to a part of the inheritance
tree. You can change them from outside the class using the class component selector with any
class name, or within any class in which they are shared. They are visible in all classes in the
inheritance tree.
When you address a static attribute that belongs to part of an inheritance tree, you always
address the class in which the attribute is declared, irrespective of the class you specify in the
class selector. This is particularly important when you call the static constructors of classes in
inheritance. Static constructors are executed the first time you address a class. If you address a
static attribute declared in a superclass using the class name of a subclass, only the static
constructor of the superclass is executed.
Inheritance and Constructors
There are special rules governing constructors in inheritance.
Instance Constructors
Every class has an instance constructor called CONSTRUCTOR. This is an exception to the rule
that states that component names within an inheritance tree must be unique. However, the
instance constructors of the various classes in an inheritance tree are fully independent of one
another. You cannot redefine the instance constructor of a superclass in a subclass, neither can
you call one specifically using the statement CALL METHOD CONSTRUCTOR. Consequently,
no naming conflicts can occur.
The instance constructor of a class is called by the system when you instantiate the class using

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. To do this, the
instance constructor of each subclass must contain a CALL METHOD SUPER-
>CONSTRUCTOR statement. 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 you call an instance constructor, you must supply values for all of its non-optional interface
parameters. There are various ways of doing this:
• Using CREATE OBJECT
If the class that you are instantiating has an instance constructor with an interface, you
must pass values to it using
EXPORTING.
If the class that you are instantiating has an instance constructor without an interface,
you do not pass any parameters.
If the class you are instantiating does not have an explicit instance constructor, you must
look in the inheritance tree for the next-highest superclass with an explicit instance
constructor. If this has an interface, you must supply values using
EXPORTING.
Otherwise, you do not have to pass any values.
SAP AG BC - ABAP Programming
Inheritance
December 1999 1383
• Using CALL METHOD SUPER->CONSTRUCTOR
If the direct superclass has an instance constructor with an interface, you must pass
values to it using
EXPORTING.
If the direct superclass has an instance constructor without an interface, you do not pass

any parameters.
If the direct superclass does not have an explicit instance constructor, you must look in
the inheritance tree for the next-highest superclass with an explicit instance constructor.
If this has an interface, you must supply values using
EXPORTING. Otherwise, you do not
have to pass any values.
In both CREATE OBJECT and CALL METHOD SUPER->CONSTRUCTOR, you must look at the
next-available explicit instance constructor and, if it has an interface, pass values to it. The same
applies to exception handling for instance constructors. When you work with inheritance, you
need an precise knowledge of the entire inheritance tree. When you instantiate a class at the
bottom of the inheritance tree, you may need 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 METHOD SUPER-
>CONSTRUCTOR statement. In the statements before the call, the constructor behaves like a
static method, that is, it cannot access the instance attributes of its class. You cannot address
instance attributes until after the call. Use the statements before the call to determine the actual
parameters for the interface of the instance constructor of the superclass. You can only use
static attributes or local data to do this.
When you instantiate a subclass, the instance constructors are called hierarchically. The first
nesting level in which you can address instance attributes is the highest-level superclass. When
you return to the constructors of the lower-level classes, you can also successively address their
instance attributes.
In a constructor method, the methods of the subclasses of the class are not visible. 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 you want to instantiate. This is an exception
to the rule that states that when you call instance methods, the system always calls the method
as it is implemented in the class to whose instance the reference is pointing.
Static Constructors
Every class has a static constructor called CLASS_CONSTRUCTOR. As far as the namespace

within an inheritance tree, the same applies to static constructors as to instance constructors.
The first time you address a subclass in a program, its static constructor is executed. However,
before it can be executed, 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 you
first address a subclass, the system looks for the next-highest superclass whose static
constructor has not yet been executed. It executes the static constructor of that class, followed
by those of all classes between that class and the subclass you addressed.
See also:
Overview Graphics [Page 1385]
BC - ABAP Programming SAP AG
Inheritance
1384 December 1999
Inheritance: Introductory Example [Page 1388]
SAP AG BC - ABAP Programming
Inheritance: Overview Graphic
December 1999 1385
Inheritance: Overview Graphic
Inheritance: Overview
Class c1

CLASS c1 DEFINITION INHERITING FROM

ENDCLASS.
CLASS c1 IMPLEMENTATION.

ENDCLASS.
CLASS c2 DEFINITION INHERITING FROM c1.

ENDCLASS.
CLASS c2 IMPLEMENTATION.

ENDCLASS.
Class c2

Class OBJECT

Class


The left-hand part of the graphic shows how you can derive a subclass c2 from a superclass c1
using the INHERTING FROM addition in the CLASS statement. The right-hand part of the
graphic shows the distribution of the subclass in the inheritance tree, which stretches back to the
default empty class OBJECT. A subclass contains all of the components declared above it in the
inheritance tree, and can address all of them that are declared public or protected.
BC - ABAP Programming SAP AG
Inheritance: Overview Graphic
1386 December 1999
Single Inheritance
C1

OBJECT
C2


This graphic illustrates single inheritance. A class may only have one direct superclass, but it can
have more than one direct subclass. The empty class OBJECT is the root node of every
inheritance tree in ABAP Objects.
Inheritance and Reference Variables
n<class3>
class1

CREF3
CREF2
CREF1
class2
class3
This graphic shows how reference variables defined with reference to a superclass can point to
objects of subclasses. The object on the right is an instance of the class class3. The class
reference variables CREF1, CREF2, and CREF3 are typed with reference to class1, class2, and
SAP AG BC - ABAP Programming
Inheritance: Overview Graphic
December 1999 1387
class3. All three can point to the object. However, CREF1 can only address the public
components of class1. CREF2 can address the public components of class1 and class2. CREF3
can address the public components of all of the classes.
If you redefine a method of a superclass in a subclass, you can use a reference variable defined
with reference to the superclass to address objects with different method implementations. When
you address the superclass, the method has the original implementation, but when you address
the subclass, the method has the new implementation. Using a single reference variable to call
identically-named methods that behave differently is called polymorphism.
BC - ABAP Programming SAP AG
Inheritance: Introductory Example
1388 December 1999
Inheritance: Introductory Example
The following simple example shows the principle of inheritance within ABAP Objects. It is based
on the Simple Introduction to Classes [Page 1359]. A new class counter_ten inherits from the
existing class counter.
REPORT demo_inheritance.
CLASS counter DEFINITION.
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.
CLASS counter IMPLEMENTATION.
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.
ENDCLASS.
CLASS counter_ten IMPLEMENTATION.
METHOD increment.
DATA modulo TYPE I.
CALL METHOD 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.
SAP AG BC - ABAP Programming
Inheritance: Introductory Example
December 1999 1389
CALL METHOD count->set EXPORTING set_value = number.
DO 20 TIMES.
CALL METHOD count->increment.
ENDDO.
The class COUNTER_TEN is derived from COUNTER. It redefines the method
INCREMENT. To do this, you must change the visibility of the COUNT attribute from
PRIVATE to PROTECTED. The redefined method calls the obscured method of the
superclass using the pseudoreference SUPER->. The redefined method is a
specialization of the inherited method.
The example instantiates the subclass. The reference variable pointing to it has the
type of the superclass. When the INCREMENT method is called using the
superclass reference, the system executes the redefined method from the subclass.
BC - ABAP Programming SAP AG
Interfaces
1390 December 1999
Interfaces
Einführendes Beispiel zu Interfaces [Page 1395]
Classes, their instances (objects), and access to objects using reference variables form the
basics of ABAP Objects. These means already allow you to model typical business applications,
such as customers, orders, order items, invoices, and so on, using objects, and to implement

solutions using ABAP Objects.
However, it is often necessary for similar classes to provide similar functions that are coded
differently in each class but which should provide a uniform point of contact for the user. For
example, you might have two similar classes, savings account and check account, both of which
have a method for calculating end of year charges. The interfaces and names of the methods are
the same, but the actual implementation is different. The user of the classes and their instances
must also be able to run the end of year method for all accounts, without having to worry about
the actual type of each individual account.
ABAP Objects makes this possible by using interfaces. Interfaces are independent structures that
you can implement in a class to extend the scope of that class. The class-specific scope of a
class is defined by its components and visibility sections. 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 of a class define its scope with regard to its
subclasses. (However, inheritance is not supported in Release 4.5B).
Interfaces extend the scope of a class by adding their own components to its public section. This
allows users to address different classes via a universal point of contact. Interfaces, along with
inheritance, provide one of the pillars of polymorphism, since they allow a single method within
an interface to behave differently in different classes.
Defining Interfaces
Like classes, you can define interfaces either globally in the R/3 Repository or locally in an ABAP
program. For information about how to define local interfaces, refer to the Class Builder [Extern]
section of the ABAP Workbench Tools documentation. The definition of a local interface <intf> is
enclosed in the statements:
INTERFACE <intf>.

ENDINTERFACE.
The definition contains the declaration for all components (attributes, methods, events) of the
interface. You can define the same components in an interface as in a class. The components of
interfaces do not have to be assigned individually to a visibility section, since they automatically
belong to the public section of the class in which the interface is implemented. Interfaces do not

have an implementation part, since their methods are implemented in the class that implements
the interface.
Implementing Interfaces
Unlike classes, interfaces do not have instances. Instead, interfaces are implemented by classes.
To implement an interface in a class, use the statement
INTERFACES <intf>.
SAP AG BC - ABAP Programming
Interfaces
December 1999 1391
in the declaration part of the class. This statement may only appear in the public section of the
class.
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 <icomp> of an interface <intf> can be
addressed as though it were a member of the class under the name <intf~icomp>.
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 <imeth>:
METHOD <intf~imeth>.

ENDMETHOD.
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 references
(polymorphism). For example, 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 References
Reference variables allow you to access objects (refer to Working with Objects [Page 1360]).
Instead of creating reference variables with reference to a class, you can also define them with
reference to an interface. This kind of reference variable can contain references to objects of

classes that implement the corresponding interface.
To define an interface reference, use the addition TYPE REF TO <intf> in the TYPES or DATA
statement. <intf> must be an interface that has been declared to the program before the actual
reference declaration occurs. A reference variable with the type interface reference is called a
interface reference variable, or interface reference for short.
An interface reference <iref> allows a user to use the form <iref>-><icomp> to address all visible
interface components <icomp> of the object to which the object reference is pointing. It allows
the user to access all of the components of the object that were added to its definition by the
implementation of the interface.
Addressing Objects Using Interface References
To create an object of the class <class>, you must first have declared a reference variable <cref>
with reference to the class. If the class <class> implements an interface <intf>, you can use the
following assignment between the class reference variable <cref> and an interface reference
<iref> to make the interface reference in <iref> point to the same object as the class reference in
<cref>:
<iref> = <cref>
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 <cref>:
• To access an attribute <attr>: <cref>-><intf~attr>
• To call a method <meth>: CALL METHOD <cref>-><intf~meth>
BC - ABAP Programming SAP AG
Interfaces
1392 December 1999
Using the interface reference variable <iref>:
• To access an attribute <attr>: <iref>-><attr>
• To call a method <meth>: CALL METHOD <iref>-><meth>
As far as the static components of interfaces are concerned, you can only use the interface name
to access constants:

Addressing 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:
Addressing a static attribute <attr>: <
class>=><intf~attr>
Calling a static method <meth>: CALL METHOD <class>=><intf~meth>
Assignment Using Interface References - Casting
Like class references, you can assign interface references to different reference variables. You
can also make assignments between class reference variables and interface reference variables.
When you use the MOVE statement or the assignment operator (=) to assign reference variables,
the system must be able to recognize in the syntax check whether an assignment is possible.
Suppose we have a class reference <cref> and interface references <iref>, <iref1>, and <iref2>.
The following assignments with interface references can be checked statically:
• <iref1> = <iref2>
Both interface references must refer to the same interface, or the interface of <iref1>
must contain the interface <iref2> as a component.
• <iref> = <cref>
The class of the class reference <cref> must implement the interface of the interface
reference <iref>.
• <cref> = <iref>
The class of <cref> must be the predefined empty class OBJECT.
In all other cases, you would have to work with the statement MOVE ? TO or the
casting
operator
(?=). The casting operator replaces the assignment operator (=). In the MOVE ? TO
statement, or when you use the casting operator, 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 can also point. If the assignment is possible,

the system makes it, otherwise, the catchable runtime error MOVE_CAST_ERROR occurs.
You must always use casting for assigning an interface reference to a class reference if <cref>
does not refer to the predefined empty class OBJECT:
<cref> ?= <iref>
For the casting to be successful, the object to which <iref> points must be an object of the same
class as the type of the class variable <cref>.
See also:
Overview Graphics [Page 1394]
SAP AG BC - ABAP Programming
Interfaces
December 1999 1393
BC - ABAP Programming SAP AG
Overview Graphics
1394 December 1999
Overview Graphics
Interfaces
All users
Class C1
Private
components
…
Method
implementations
Subclasses of C1
Protected components
…
Public
components
A1,

CLASS C1 DEFINITION.
PUBLIC SECTION.
INTERFACES I1.
DATA: A1 …
…
PROTECTED SECTION.
…
PRIVATE SECTION.
…
ENDCLASS.
CLASS C1 IMPLEMENTATION.
METHOD I1~M1.
…
ENDMETHOD.
…
ENDCLASS.
INTERFACE I1.
DATA: A1 …
METHODS: M1 …
EVENTS: E1 …
ENDINTERFACE.
I1~A1,
I1~M1,
I1~E1

[Extern] [Extern]
The left-hand side of the diagram shows the definition of a local interface I1 and the declaration
and implementation parts of a local class C1 that implements the interface I1 in its
public
section

. The interface method I1~M1 is implemented in the class. You cannot implement
interfaces in the other visibility sections.
The right-hand side illustrates the structure of the class with the components in their respective
visibility areas, and the implementation of the methods. The interface components extend the
public scope of the class. All users can access the public components specific to the class and
those of the interface.
SAP AG BC - ABAP Programming
Interfaces - Introductory Example
December 1999 1395
Interfaces - Introductory Example
The following simple example shows how you can use an interface to implement two counters
that are different, but can be addressed in the same way. See also the example in the Classes
section.
INTERFACE I_COUNTER.
METHODS: SET_COUNTER IMPORTING VALUE(SET_VALUE) TYPE I,
INCREMENT_COUNTER,
GET_COUNTER EXPORTING VALUE(GET_VALUE) TYPE I.
ENDINTERFACE.
CLASS C_COUNTER1 DEFINITION.
PUBLIC SECTION.
INTERFACES I_COUNTER.
PRIVATE SECTION.
DATA COUNT TYPE I.
ENDCLASS.
CLASS C_COUNTER1 IMPLEMENTATION.
METHOD I_COUNTER~SET_COUNTER.
COUNT = SET_VALUE.
ENDMETHOD.
METHOD I_COUNTER~INCREMENT_COUNTER.
ADD 1 TO COUNT.

ENDMETHOD.
METHOD I_COUNTER~GET_COUNTER.
GET_VALUE = COUNT.
ENDMETHOD.
ENDCLASS.
CLASS C_COUNTER2 DEFINITION.
PUBLIC SECTION.
INTERFACES I_COUNTER.
PRIVATE SECTION.
DATA COUNT TYPE I.
ENDCLASS.
CLASS C_COUNTER2 IMPLEMENTATION.
METHOD I_COUNTER~SET_COUNTER.
COUNT = ( SET_VALUE / 10) * 10.
ENDMETHOD.
METHOD I_COUNTER~INCREMENT_COUNTER.
IF COUNT GE 100.
MESSAGE I042(00).
COUNT = 0.
ELSE.
ADD 10 TO COUNT.
ENDIF.
ENDMETHOD.
METHOD I_COUNTER~GET_COUNTER.
GET_VALUE = COUNT.
BC - ABAP Programming SAP AG
Interfaces - Introductory Example
1396 December 1999
ENDMETHOD.
ENDCLASS.

The interface I_COUNTER contains three methods SET_COUNTER,
INCREMENT_COUNTER, and GET_COUNTER. The classes C_COUNTER1 and
C_COUNTER2 implement the interface in the public section. Both classes must
implement the three interface methods in their implementation part. C_COUNTER1
is a class for counters that can have any starting value and are then increased by
one. C_COUNTER2 is a class for counters that can only be increased in steps of 10.
Both classes have an identical outward face. It is fully defined by the interface in both
cases.
The following sections explain how a user can use an interface reference to address
the objects of both classes:
[Extern]
SAP AG BC - ABAP Programming
Triggering and Handling Events
December 1999 1397
Triggering and Handling Events
Übersichtsgrafiken zu Ereignissen [Page 1400]
Einführendes Beispiel zu Ereignissen [Page 1403]
Komplexes Beispiel zu Ereignissen [Page 1405]
In ABAP Objects, triggering and handling an event means that certain methods act as triggers
and trigger events, to which other methods - the handlers - react. This means that the handler
methods are executed when the event occurs.
This section contains explains how to work with events in ABAP Objects. For precise details of
the relevant ABAP statements, refer to the corresponding keyword documentation in the ABAP
Editor.
Triggering Events
To trigger an event, a class must
• Declare the event in its declaration part
• Trigger the event in one of its methods
Declaring Events
You declare events in the declaration part of a class or in an interface. To declare instance

events, use the following statement:
EVENTS <evt> EXPORTING VALUE(<e
i
>) TYPE type [OPTIONAL]
To declare static events, use the following statement:
CLASS-EVENTS <evt>
Both statements have the same syntax.
When you declare an event, you can use the EXPORTING addition to specify parameters that
are passed to the event handler. The parameters are always passed by value. Instance events
always contain the implicit parameter SENDER, which has the type of a reference to the type or
the interface in which the event is declared.
Triggering Events
An instance event in a class can be triggered by any method in the class. Static events can be
triggered by any static method. To trigger an event in a method, use the following statement:
RAISE EVENT <evt> EXPORTING <e
i
> = <f
i
>
For each formal parameter <e
i
> that is not defined as optional, you must pass a corresponding
actual parameter <f
i
> in the EXPORTING addition. The self-reference ME is automatically
passed to the implicit parameter SENDER.
Handling Events
Events are handled using special methods. To handle an event, a method must
• be defined as an event handler method for that event
• be registered at runtime for the event.

BC - ABAP Programming SAP AG
Triggering and Handling Events
1398 December 1999
Declaring Event Handler Methods
Any class can contain event handler methods for events from other classes. You can, of course,
also define event handler methods in the same class as the event itself. To declare an event
handler method, use the following statement:
METHODS <meth> FOR EVENT <evt> OF <cif> IMPORTING <e
i
>
for an instance method. For a static method, use CLASS-METHODS instead of METHODS.
<evt> is an event declared in the class or interface <cif>.
The interface of an event handler method may only contain formal parameters defined in the
declaration of the event <evt>. The attributes of the parameter are also adopted by the event.
The event handler method does not have to use all of the parameters passed in the RAISE
EVENT statement. If you want the implicit parameter SENDER to be used as well, you must list
it in the interface. This parameter allows an instance event handler to access the trigger, for
example, to allow it to return results.
If you declare an event handler method in a class, it means that the instances of the class or the
class itself are, in principle, able to handle an event <evt> triggered in a method.
Registering Event Handler Methods
To allow an event handler method to react to an event, you must determine at runtime the trigger
to which it is to react. You can do this with the following statement:
SET HANDLER <h
i
> [FOR]
It links a list of handler methods with corresponding trigger methods. There are four different
types of event.
It can be
• An instance event declared in a class

• An instance event declared in an interface
• A static event declared in a class
• A static event declared in an interface
The syntax and effect of the SET HANDLER depends on which of the four cases listed above
applies.
For an instance event, you must use the FOR addition to specify the instance for which you want
to register the handler. You can either specify a single instance as the trigger, using a reference
variable <ref>:
SET HANDLER <h
i
> FOR <ref>.
or you can register the handler for all instances that can trigger the event:
SET HANDLER <h
i
> FOR ALL INSTANCES.
The registration then applies even to triggering instances that have not yet been created when
you register the handler.
You cannot use the FOR addition for static events:
SET HANDLER <h
i
>
SAP AG BC - ABAP Programming
Triggering and Handling Events
December 1999 1399
The registration applies automatically to the whole class, or to all of the classes that implement
the interface containing the static event. In the case of interfaces, the registration also applies to
classes that are not loaded until after the handler has been registered.
Timing of Event Handling
After the RAISE EVENT statement, all registered handler methods are executed before the next
statement is processed (synchronous event handling). If a handler method itself triggers events,

its handler methods are executed before the original handler method continues. To avoid the
possibility of endless recursion, events may currently only be nested 64 deep.
Handler methods are executed in the order in which they were registered. Since event handlers
are registered dynamically, you should not assume that they will be processed in a particular
order. Instead, you should program as though all event handlers will be executed simultaneously.
BC - ABAP Programming SAP AG
Overview Graphic
1400 December 1999
Overview Graphic
Suppose we have two classes, C1 and C2:
CLASS C2 DEFINITION.
PUBLIC SECTION.
METHODS: M2
FOR EVENT E1 OF C1
IMPORTING P1.
PRIVATE SECTION.
DATA A2 TYPE I.
ENDCLASS.
CLASS C2 IMPLEMENTATION.
METHOD M2.
A2 = P1.

ENDMETHOD.
ENDCLASS.
CLASS C1 DEFINITION.
PUBLIC SECTION.
EVENTS E1
EXPORTING VALUE(P1)
TYPE I.
METHODS M1.

PRIVATE SECTION.
DATA A1 TYPE I.
ENDCLASS.
CLASS C1 IMPLEMENTATION.
METHOD M1.
A1 =
RAISE EVENT E1
EXPORTING P1 = A1.
ENDMETHOD.
ENDCLASS.
Event trigger Event handler
The class C1 contains an event E1, which is triggered by the method M1. Class C2 contains a
method M2, which can handle event E1 of class C1.
The following diagram illustrates handler registration:
SAP AG BC - ABAP Programming
Overview Graphic
December 1999 1401
R1 H1
H2
C2<1>
C2<2>
E1
….
M2
M2
DATA: R1 TYPE REF TO C1,
H1 TYPE REF TO C2,
H2 TYPE REF TO C2.
CREATE OBJECT: R1,
H1,

H2.
SET HANDLER H1->M2
H2->M2 FOR R1.
CALL METHOD R1->M1.
C1<1>
Registering handlers
The program creates an instance of the class C1 and two instances of the class C2. The values
of the reference variables R1, H1, and H2 point to these instances.
The SET HANDLER statement creates a handler table, invisible to the user, for each event for
which a handler method has been registered.
The handler table contains the names of the handler methods and
references to the registered
instances. The entries in the table are administered dynamically by the SET HANDLER
statement. A reference to an instance in a handler table is like a reference in a reference
BC - ABAP Programming SAP AG
Overview Graphic
1402 December 1999
variable. In other words, it counts as a use of the instance, and therefore directly affects its
lifetime. In the above diagram, this means that the instances C2<1> and C2<2> are not deleted
by the garbage collection, even if H1 and H2 are initialized, so long as their registration is not
deleted from the handler table.
For static events, the system creates an instance-independent handler table for the relevant
class.
When an event is triggered, the system looks in the corresponding event table and executes the
methods in the appropriate instances (or in the corresponding class for a static handler method).
SAP AG BC - ABAP Programming
Events: Introductory Example
December 1999 1403
Events: Introductory Example
The following simple example shows the principle of events within ABAP Objects. It is based on

the Simple Introduction to Classes [Page 1359]. An event critical_value is declared and triggered
in class counter.
REPORT demo_class_counter_event.
CLASS counter DEFINITION.
PUBLIC SECTION.
METHODS increment_counter.
EVENTS critical_value EXPORTING value(excess) TYPE i.
PRIVATE SECTION.
DATA: count TYPE i,
threshold TYPE i VALUE 10.
ENDCLASS.
CLASS counter IMPLEMENTATION.
METHOD increment_counter.
DATA diff TYPE i.
ADD 1 TO count.
IF count > threshold.
diff = count - threshold.
RAISE EVENT critical_value EXPORTING excess = diff.
ENDIF.
ENDMETHOD.
ENDCLASS.
CLASS handler DEFINITION.
PUBLIC SECTION.
METHODS handle_excess
FOR EVENT critical_value OF counter
IMPORTING excess.
ENDCLASS.
CLASS handler IMPLEMENTATION.
METHOD handle_excess.
WRITE: / 'Excess is', excess.

ENDMETHOD.
ENDCLASS.
DATA: r1 TYPE REF TO counter,
h1 TYPE REF TO handler.
START-OF-SELECTION.
CREATE OBJECT: r1, h1.
SET HANDLER h1->handle_excess FOR ALL INSTANCES.
DO 20 TIMES.
CALL METHOD r1->increment_counter.
ENDDO.
BC - ABAP Programming SAP AG
Events: Introductory Example
1404 December 1999
The class COUNTER implements a counter. It triggers the event CRITICAL_VALUE
when a threshold value is exceeded, and displays the difference. HANDLER can
handle the exception in COUNTER. At runtime, the handler is registered for all
reference variables that point to the object.