Advanced

ABAP Objects
Programming
Horst Keller / Stefan Bresch
Business Programming Languages, SAP AG
Overview

Interfaces and Inheritance

Visibility and Access
Method Call
Object Services
Interfaces and Inheritance

Abstract and Final Classes and Methods

Composing Interfaces

Polymorphism

Polymorphic Event Handling

Interfaces and Inheritance – Principles

ABAP Objects supports single inheritance

CLASS c1 DEFINITION.
...
CLASS c2 DEFINITION INHERITING FROM c1.
...
CLASS c3 DEFINITION INHERITING FROM c1.
...

Classes can implement several interfaces

INTERFACE i1.
...
INTERFACE i2.
...
CLASS c1 DEFINITION.
PUBLIC SECTION.
INTERFACES: i1, i2.
...
 Abstract and Final Classes and Methods

Abstract Classes and Methods

CLASS c1 DEFINTION ABSTRACT. CLASS c1 IMPLEMENTATION.
METHODS: m1, METHODS m1.
m2 ABSTRACT. ENDMETHOD.
ENDCLASS. ENDCLASS.

 Abstract classes can‘t be instantiated

 Abstract methods can only be implemented in a
subclass, using REDEFINITION.
 A class containing an abstract method must itself be
abstract.
 Compared to interfaces, abstract classes can be partly
implemented but are restricted by single inheritance.
 Abstract and Final Classes and Methods

Final Classes and Methods

CLASS c1 DEFINTION FINAL. CLASS c2 DEFINITION.

METHODS: m1, METHODS: m1,
m2. m2 FINAL.
ENDCLASS. ENDCLASS.

 Final classes can‘t have subclasses.

 Final methods can‘t be redefined.
 All methods of a final class are implicitly final.
 Final classes are endnodes of the inheritance tree.
Interfaces – Implementation 6.10

New additions for implementation in classes:

CLASS class DEFINITION.

PUBLIC SECTION.
INTERFACES intf
intf.
[ABSTRACT METHODS meth ...]
[FINAL METHODS meth ...]
[ALL METHODS ABSTRACT|FINAL]
[DATA VALUES attr = value ...].
...

 You can make interface methods abstract or final.

 You can assign start values to interface attributes.
Composing Interfaces

Composing Interfaces

INTERFACE i1.
...
...
INTERFACES i2, i3, ...
...
ENDINTERFACE.

 i1: Compound Interface

 i2, i3, ... : Component Interfaces
Composing Interfaces – Naming

INTERFACE i2.
INTERFACES i1.
ENDINTERFACE.

INTERFACE i3.
INTERFACES i1, i2.
ENDINTERFACE.

 i3 contains i1 exactly once

 The name of i1 in i3 is i3~i1
 No nesting of names (i3~i2~i1) allowed
Composing Interfaces – Diamond Inheritance

INTERFACE i1.
METHODS meth.
ENDINTERFACE.

INTERFACE i2. INTERFACE i3.

INTERFACES i1. INTERFACES i1.
METHODS meth. METHODS meth.
ENDINTERFACE. ENDINTERFACE.

INTERFACE i4.
INTERFACES i2, i3.
ENDINTERFACE.
Problem?
Composing Interfaces – Implementation

No Problem! CLASS c1 DEFINITION.

PUBLIC SECTION.
INTERFACES i4.
 Each interface is ENDCLASS.
implemented once.
CLASS c1 IMPLEMENTATION.
 All interfaces are METHOD i1~meth.
implemented at the same ...
level. ENDMETHOD.
METHOD i2~meth.
 Each interface ...
component is unique. ENDMETHOD.
METHOD i3~meth.
...
ENDMETHOD.
ENDCLASS.
 Composing Interfaces – Aliases

INTERFACE i1.
METHODS m1.  Inside: Access to deep
ENDINTERFACE. components of compound
INTERFACE i2. interfaces via aliases only.
INTERFACES i1.  Outside: Narrowing cast.
ALIASES m2 FOR i1~m1.
ENDINTERFACE.

INTERFACE i3.
INTERFACES i2.
ALIASES m3 FOR i2~m2. FOR i2~i1~m1.
ENDINTERFACE.

DATA: iref1 TYPE REF TO i1,

iref3 TYPE REF TO i3.
iref1 = iref3.
iref1->m1( ). iref3->i2~i1~m1( ).
iref3->m3( ).
Polymorphism

Polymorphism

Accessing different methods in different objects

and with different behavior via the same
interface.

 You access objects via reference variables.

 You can use one and the same reference
variable to access various objects.
 What is the technical background?
 Polymorphism – Reference Variables

 Object:

CREATE OBJECT oref TYPE class.

Instance of a class.
 Reference Variable:
DATA oref TYPE REF TO class|interface. oref

Typed with a class or an interface

 Reference Variable Types:

Static Type - from typing

Dynamic Type - class of object
Polymorphism – Static and Dynamic Types

Golden Rule
The static type must be more general than or
equal to the dynamic type.

 If the static type is an interface, the dynamic

type must implement the interface.
 If the static type is a class, the dynamic type
must be the same class or one of its
subclasses.
 Different static and dynamic types:
Polymorphism
 Polymorphism – Reference Variable Assignments

Two cases for assignments:

1. Golden rule can be tested statically:
Static type of target is more general than or equal to
static type of source.

 Narrowing (Up) Cast

2. Golden rule cannot be tested statically:
Static type of target is more special than static type of
source.

 Widening (Down) Cast

 Polymorphism – Narrowing Cast

Static tests of golden rule:

 Static types of target and source are classes:
Target class is superclass of or the same as source class.
 Static types of target and source are interfaces:
Target interface is component of or the same as source interface.
 Static type of target is interface and static type of source is class:
Target interface is implemented in source class or one of its super
classes.
 Static type of target is class and static type of source is interface:
Target class is the root class “object“.
 Polymorphism – Widening Cast

No static tests of golden rule possible:

 All cases that cannot be handled by narrowing cast.
 No other assignments possible than with
casting operator ?= (MOVE ... ?TO ...).

DATA: oref1 TYPE REF TO class,

oref2 TYPE REF TO interface.
...
CREATE OBJECT oref1 TYPE class.
...
TRY.
oref1 ?= oref2.
CATCH cx_sy_move_cast_error.
...
ENDTRY.
 Polymorphic Event Handling

Principle
The event handler defines the
objects that can trigger the EVENTS evt
event handler method.

Inheritance case:
METHODS handler
FOR EVENT evt OF class. class
 Polymorphic Event Handling – Type Check 6.10

Strict type check for event handler during registration.

CLASS c1 DEFINITION. CLASS c3 DEFINITION.

PUBLIC SECTION. PUBLIC SECTION.
EVENTS e1. CLASS-METHODS handler
ENDCLASS. c2.
FOR EVENT e1 OF c1.
CLASS c2 DEFINITION ENDCLASS.
INHERITING FROM c1.
... DATA trigger TYPE REF TO c2.
c1.
ENDCLASS. SET HANDLER c3=>handler FOR trigger.

Object type behind FOR EVENT OF in declaration of handler

must be more general or the same as static type of trigger.
Polymorphic Event Handling – Type of Sender 6.10

New data type of sender.

CLASS c_handler DEFINITION.

PUBLIC SECTION.
[CLASS-]METHODS handler
FOR EVENT evt OF class|interface
IMPORTING sender ...
ENDCLASS.

Data type of the implicit event parameter sender is the

object type class or interface behind FOR EVENT OF.
Before release 6.10 the type was defined by the class or
interface where the event was declared.
Visibility and Access

Read-Only Attributes
Attributes in Internal Tables
Dynamic Access
Restricted Instantiation
Friends
Visibility – Read-Only Attributes

CLASS c1 DEFINITION.
PUBLIC SECTION.
METHODS get_a1 RETURNING r1 ...
PRIVATE SECTION.
DATA a1 TYPE ...
CLASS c1 IMPLENTATION.
ENDCLASS.
METHOD get_a1.
r1 = a1.
Text book style ... ENDMETHOD.
ENDCLASS.
but performance?

CLASS c1 DEFINITION.
PUBLIC SECTION.
DATA a1 TYPE ... READ-ONLY.
...
ENDCLASS.
 Access – Attributes in Internal Table Operations

Did you know?

DATA: BEGIN OF itab_line,
idx TYPE i,
oref TYPE REF TO class|interface,
END OF itab_line.
DATA itab LIKE TABLE OF itab_line.
SORT itab BY oref->attr ...
DELETE itab WHERE oref->attr = ...
READ TABLE itab INTO itab_line WITH KEY oref->attr = ...
MODIFY itab FROM itab_line TRANSPORTING oref
WHERE oref->attr = ...
LOOP AT itab INTO itab_line WHERE oref->attr > 1.
...
ENDLOOP.
 Access – Dynamic Access 6.10

Principle: Access to all visible components

 Static type more general than dynamic type.
 Static access only to statically known components.
 Dynamic Access
DATA oref TYPE REF TO object.
FIELD-SYMBOLS <fs> TYPE ANY.
DATA attr TYPE string.
create object oref type class.
attr = 'ATTR'.
ASSIGN oref->(attr) TO <fs>. Check by sy-subrc
attr = 'OREF->ATTR'. or IS ASSIGNED .
ASSIGN (attr) TO <fs>.
Access – Restricted Instantiation
Visibility of Instance Constructor
CLASS class DEFINITION
DEFINITION.CREATE PUBLIC|PROTECTED|PRIVATE.
PUBLIC SECTION.  ???
METHODS constructor ...

 Declaration of constructor in public section.

 Constructor is called by CREATE OBJECT statement
 Constructor visibility set implicitly by CREATE addition.
 Subclasses inherit constructor visibility or override it.
But:
Subclasses of superclass with addition CREATE PRIVATE cannot
be instantiated (exception: FRIENDS)
They always inherit the implicit addition CREATE NONE.
Classes with addition CREATE PRIVATE should be FINAL.
Access – Friends 6.10

Giving up Protection and Privacy

CLASS class DEFINITION CREATE PROTECTED|PRIVATE
CLASS class DEFINITION CREATE PROTECTED|PRIVATE.
FRIENDS classes interfaces ...
...
...
PROTECTED|PRIVATE SECTION.
PROTECTED|PRIVATE SECTION.

 A class can offer friendship to other classes or interfaces.

 Subclasses of friends and all classes/interfaces that implement a
friend interface are also friends.
 Friends have access to all components of a class.
 Friends can allways instantiate a class.
 A class offering friendship is not automatically friend of its friends.
 Offering friendship is not inherited by subclasses.
Method Call

Functional Methods

Short Form for Static Invoke

Dynamic Invoke

Invoke via OO-Transaction

Method Call – Functional Methods

Methods with one RETURNING PARAMETER.

METHODS meth IMPORTING ... pi ...
RETURNING VALUE(r) TYPE ...

Short forms can be used in operand positions.

meth( ). f = meth( ).
meth( a ). [COMPUTE] r = f + meth( ).
meth( pi = ai ... ). ... meth( ) > f.
CASE meth( ).
WHEN meth( ).

6.10 Built-in functions also in above operand positions.

Method Call – Short Form for Static Invoke 6.10
4.6

CALL METHOD optional in Static Invoke

CALL METHOD
meth( methpiEXPORTING
meth(
EXPORTING = ai ... pi = ai ...
IMPORTING pjIMPORTING pj = aj ... ).
= aj ... ).
CALL METHOD
meth( ). meth( ).
CALL METHOD
meth( a ). meth( a ).
CALL METHOD
meth( meth(
pi = ai pi = ai ... ).
... ).

When the passing of parameters is done in parenthesis,

the keyword CALL METHOD is not necessary .

* Examples
transaction_manager->start( ).
html_viewer->show_url( url ).
Method Call – Dynamic Invoke

Dynamic Passing of Parameters

TYPE-POOLS abap.
DATA: ptab TYPE abap_parmbind_tab,
ptab_line LIKE LINE OF ptab.
ptab_line-name = 'P'.
GET REFERENCE OF a INTO ptab_line-value.
INSERT ptab_line INTO TABLE ptab.
TRY.
meth = 'METH'.
CALL METHOD oref->(meth)
PARAMETER-TABLE ptab.
CATCH cx_sy_dyn_call_error.
...
ENDTRY.

6.10 PARAMETER-TABLE also in CALL FUNCTION.

 Method Call – OO-Transaction 6.10

Transaction Code

Object Services

Global or Local

PROGRAM demo_oo_transaction. Calling the

CLASS demo_class DEFINITION. transaction loads
PUBLIC SECTION. the program into an
METHODS instance_method.
own internal mode,
ENDCLASS.
instantiates the
CLASS demo_class IMPLEMENTATION.
class and executes
METHOD instance_method.
... the method.
ENDMETHOD.
ENDCLASS. Program
Object Services 6.10

Introduction
Transparent Object Persistence
Handling persistent Objects
Additional transaction service
 Object Services - Introduction 6.10

ABAP program  Object services are language-

related services that are not part
of the language itself,
Persistent
objects  provide a level of abstraction
between ABAP programs and the
Object Services runtime environment,
 support object-oriented handling
System of persistent data and
and class- transactions,
specific agents
 are realized in the Class Library in
classes CL_OS_... and interfaces
ABAP runtime environment IF_OS_... .

Database
Object Services - Transparent Object Persistence
6.10

Persistence Service
Persistent Classes
Object-relational Mapping
Persistence Representation
Object Services - Persistence Service 6.10

Object Services offers you a transparent

object persistence.
The persistence of your objects is managed
by the persistence service.
 The persistence service loads your objects.
 The persistence service tracks the changes
made to your objects.
 The persistence service stores your (changed)
objects.
Object Services - Persistent Classes 6.10

The persistence service handles instances of

persistent classes. With the Class Builder, you
can create a persistent class.
Object Services - Object-Relational Mapping 6.10

Mapping classes to tables and objects to table

rows is called the object-relational mapping.

CL_CARRIER

CARRID
CARRNAME SCARR
...
CARRID CARRNAME...

...
CARRID = LH LH Lufthansa ...
...
CARRNAME = Lufthansa

...
Object Services - Persistence Representation 6.10

 For a persistent class, the object-relational

mapping can be defined within the Class
Builder.
 The „persistence representation“ tool can be
accessed using the button Persistence .

 Here, starting with fields of an existing table,

persistent attributes can be created.
Object Services - Handling Persistent Objects 6.10

Accessor Methods
Life Cycle Management Methods
Class Agents
Loading, Creating, Deleting, ...
Object Identity
Persistent Object References
Object Services - Accessor Methods 6.10

 The Class Builder generates accessor

methods for each attribute of a persistent
class.
 The attribute A of a persistent class can only
be accessed with the methods GET_A and
SET_A.
 The accessor methods inform the
persistence service of attribute access.
Object Services - Life Cycle Management Methods
6.10

With the life cycle management methods, you

can handle the life cycle of persistent
instances.
 Methods for creating persistent instances.
 Methods for loading persistent instances.
 Methods for deleting persistent instances.

A persistent instance has one of the following

life cycle states: NEW, LOADED, CHANGED,
DELETED, NOT_LOADED.
Object Services - Class Agents 6.10

 The life cycle management methods are

provided by the class agent.
 The class agent is generated by the Class
Builder.
 The class agent for the persistent class
CL_X is named CA_X.
 The class agent is a singleton and has a
class attribute AGENT containing an object
reference to this singleton.
Object Services - Loading a Persistent Object 6.10

A persistent object can be loaded with the class

agent method GET_PERSISTENT.
DATA: CARRIER TYPE REF TO CL_CARRIER,
CARRIER_AGENT TYPE REF TO CA_CARRIER,
CARRNAME TYPE S_CARRNAME.

CARRIER_AGENT = CA_CARRIER=>AGENT.

TRY.
CARRIER = CARRIER_AGENT->GET_PERSISTENT(
I_CARRID = 'LH' ).
CARRNAME = CARRIER->GET_CARRNAME( ).
WRITE: 'LH: ', CARRNAME.
CATCH CX_OS_OBJECT_NOT_FOUND.
ENDTRY.
Object Services - Creating a Persistent Object 6.10

A persistent object can be created with the class

agent method CREATE_PERSISTENT.
DATA: CARRIER TYPE REF TO CL_CARRIER,
CARRIER_AGENT TYPE REF TO CA_CARRIER.

CARRIER_AGENT = CA_CARRIER=>AGENT.

TRY.
CARRIER = CARRIER_AGENT->CREATE_PERSISTENT(
I_CARRID = 'LH' ).
CARRIER->SET_CARRNAME('Lufthansa' ).
CATCH CX_OS_OBJECT_EXISTING.
ENDTRY.

COMMIT WORK.
Object Services - Deleting a Persistent Object 6.10

A persistent object can be deleted with the class

agent method DELETE_PERSISTENT.
DATA: CARRIER_AGENT TYPE REF TO CA_CARRIER.

CARRIER_AGENT = CA_CARRIER=>AGENT.

TRY.
CARRIER_AGENT->DELETE_PERSISTENT(
I_CARRID = 'LH' ).
CATCH CX_OS_OBJECT_NOT_EXISTING.
ENDTRY.

COMMIT WORK.
Object Services – Object Identity 6.10

Object identity business key:

The object identity is controlled by the application. (The
business keys are the attributes mapped to the primary
key fields of the table mapped to this persistent class.)
Object identity GUID:
The object Identity is controlled by the persistence
service. (There‘s a GUID related to each persistent object.
The GUID is not an attribute of the persistent class, but
the primary key field of the table mapped to this
persistent class.)
Object Services – Persistent Object References 6.10

A persistent attribute can be a reference to another

persistent object with object identity GUID.
Runtime references are converted to persistent
references during database access (and vice versa).
The persistent service supports transparent navigation.
A referenced object is not loaded until it is accessed.
Object Services – Transaction Service 6.10

Transaction service
Transactions
Nested transactions
Transactions and the SAP-LUW
Object Services – Transaction Service 6.10

Object Services offers you an additional transaction

service.
Inside an OO-transaction (with OO transaction model
checked) you must use the transaction service with the
specified update mode.
Object Services – Transactions 6.10

Transactions are managed by the transaction manager

(singleton created by the runtime system).
A transaction is represented by a transaction object.
A transaction is started by the START and completed by
the END method (UNDO rolls the transaction back).
DATA: TM TYPE IF_OS_TRANSACTION_MANAGER.
DATA: T TYPE IF_OS_TRANSACTION.

TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).
T = TM->CREATE_TRANSACTION( ).

T->START( ).
* Inside the transaction
T->END( ).
Object Services – Nested Transactions 6.10

 Object Services support nested transactions.

 Within a transaction, a subtransaction can be started.
 The top-level transaction is the transaction that is
active and not a subtransaction.
 If UNDO is called for a subtransaction, the state of the
instances is restored in memory.
 If END is called for a subtransaction , the before-image
of the changed instances is discarded.
Object Services – Transactions and the SAP-LUW 6.10

The object services transactions are tightly coupled with

the SAP-LUW concept. There are two scenarios for this
coupling.
 A legacy application (standard ABAP application)
calls object services components (components
using object services persistence service). The
legacy application executes COMMIT WORK.
 An object services application (application using
object services persistence and transaction
service) calls legacy components (standard ABAP
components). At top-level transaction completion
(using the method END), the transaction services
executes COMMIT WORK implicitly.