METHODS

Variants:

1. METHODS meth.

2. METHODS meth FOR EVENT evt OF cif.

You can only use this statement in the declaration part of a class declaration (see CLASS ) or in an interface definition (see INTERFACE). Instance methods belong to the components of a class.

Use the CALL METHOD statement to call methods. If a method has one RETURNING parameter and otherwise only has IMPORTING parameters, it is known as a functional method and can be called as an operand in expressions. Within a class, you can call methods by name. Instance methods are instance-specific, so you can only call them from outside the class using reference variables1 that contain references to an object in their class. Whether or not a method can be called from outside its class depends on its visibility.

Note

You cannot give names to methods that are already reserved for built-in ABAP functions, such as ABS, SIN oder SQRT, since this may lead to ambiguities when functional methods are called.

Variant 1

METHODS meth.

Extras:

1. ... ABSTRACT

2. ... FINAL

3. ... REDEFINITION

4. ... IMPORTING
           [VALUE(|REFERENCE(]p1[)] TYPE type | LIKE f
                                    [OPTIONAL|DEFAULT g]
           ...
           [VALUE(|REFERENCE(]pn[)] TYPE type | LIKE f
                                    [OPTIONAL|DEFAULT g]
           [PREFERRED PARAMETER pi]

5. ... EXPORTING
           [VALUE(|REFERENCE(]p1[)] TYPE type | LIKE f
           ...
           [VALUE(|REFERENCE(]pn[)] TYPE type | LIKE f

6. ... CHANGING
           [VALUE(|REFERENCE(]p1[)] TYPE type | LIKE f
                                    [OPTIONAL|DEFAULT g]
           ...
           [VALUE(|REFERENCE(]pn[)] TYPE type | LIKE f
                                    [OPTIONAL|DEFAULT g]

7. ... RETURNING VALUE(p) TYPE type | LIKE f

8. ... RAISING cx1 ... cxn

9. ... EXCEPTIONS p1 ... pn

Abstract, Final, and Redefined Methods

Effect

Declares Methods in a Class.

The first three additions of the METHODS statement are part of the Inheritance concept for classes. They allow you to declare abstract methods, final methods, and to redefine methods in subclasses. Abstract methods are defined in a superclass, but only implemented in a subclass. Conversely, final methods cannot be redefined in subclasses. Redefinition allows you adapt methods that have been defined in a superclass.

Notes

You cannot use additions 1-3 of the METHODS statement when declaring methods in an interface.
The ABSTRACT and FINAL additions are mutually exclusive.
You must include the ABSTRACT or FINAL addition in a statement before additions 4 to 9.
The REDEFINITION addition cannot be used in conjunction with either the ABSTRACT addition or additions 4 to 9.

Addition 1

... ABSTRACT

Effect

Declaring Abstract Instance Methods.

You use this addition to declare an instance method without its implementation. Such methods are known as abstact. Methods that are implemented are known as concrete. You must therefore include the ABSTRACT addition in the CLASS class DEFINITION as well.
You can implement abstract methods in a subclass of the class. All subsequent subclasses that do not implement the method must also be abstract. To implement an abstract method in a subclass, you need to redefine this subclass using the REDEFINITION addition.

A method can be abstract in several superclasses of the inheritance tree. Their associated classes are also abstract. In the subclass that implements it however - and in all its subclasses - the method becomes irreversibly concrete. Concrete methods cannot be made abstract again in subsequent subclasses. You cannot use the REDEFINITION addition in conjunction with the ABSTRACT addition.

An abstract method cannot also be final and you cannot use the FINAL addition in conjunction with the ABSTRACT addition.

The constructors of a class are always final, which means that you cannot declare them with the ABSTRACT addition.

Addition 2

... FINAL

Effect

Deklaring Final Instance Methods.

You use this addition to prevent methods being redefined in subclasses. Such methods are known as final. Since all methods of final classes are automatically final, you do not need to declare them as final explicitly. (Final classes are classes that are defined using the FINAL addition in the CLASS class DEFINITION statement).

Final methods cannot also be abstract.You cannot use the FINAL addition in conjunction with the ABSTRACT addition. The only exceptions to this rule are abstract methods of final classes. However, such methods can never be implemented, so it does not make sense to define them in the first place. Neither is there any point in characterizing private methods as final, since they are not visible in any subclasses of the class.

The constructors of the class are always final implicitly. You can use the FINAL addition with a constructor but there is no point.

Addition 3

... REDEFINITION

Effect

Redefinition and New Implementations of Instance Methods

You use this addition to redefine methods inherited from superclasses. At present, you cannot use any other addition with the REDEFINITION addition, except FINAL. This means that REDEFINITION must be the last expression in the statement. At present, you cannot change the method interface, nor can you declare it as abstract using the ABSTRACT addition. Within an inheritance tree, you can redefine a method in any subclass, provided it is not in a subclass characterized with the FINAL addition.

You must redefine the method in the same visibility area. When you redefine the method in the subclass, this does not affect the implementation of the method in the superclass. The redefined method is implemented with the same name in the subclass. It obscures the original method of one of the superclasses for each reference that points to an object of the subclass. The obscured method can be called in the redefined method using the pseudo-reference SUPER->.

The method must be implemented in the implementation part of the class. The method can be implemented any way you wish. The redefined method has the same interface as the method of the superclass, but can have other functions. Redefining methods, like interfaces, introduces polymorphism in classes. You often simply extend the functions of methods in the superclass that can be called in the redefined method using the pseudo-reference SUPER->.

You must use the the REDEFINITION addition, if you want to implement an abstract method of a superclass in a subclass. However, you cannot redefine a method, if it has already been declared as a final method in a superclass.

The constructors of a class are always final and cannot be redefined.

Example

CLASS C_BIKE DEFINITION ABSTRACT.
PUBLIC SECTION.
   METHODS: DRIVE ABSTRACT,
            STOP.
   PROTECTED SECTION.
     DATA SPEED TYPE I.
ENDCLASS.

CLASS C_BIKE IMPLEMENTATION.
  METHOD STOP.
    SPEED = 0.
    WRITE: / 'Bike speed =', SPEED.
  ENDMETHOD.
ENDCLASS.

CLASS C_BICYCLE DEFINITION INHERITING FROM C_BIKE.
  PUBLIC SECTION.
    METHODS DRIVE FINAL REDEFINITION.
ENDCLASS.

CLASS C_BICYCLE IMPLEMENTATION.
  METHOD DRIVE.
    SPEED = SPEED + 10.
    WRITE: / 'Bicycle speed =', SPEED.
  ENDMETHOD.
ENDCLASS.

CLASS C_MOTORCYCLE DEFINITION INHERITING FROM C_BIKE.
  PUBLIC SECTION.
    DATA IGNITION(1) TYPE C VALUE 'X'.
    METHODS: DRIVE FINAL REDEFINITION,
             STOP  FINAL REDEFINITION.
ENDCLASS.

CLASS C_MOTORCYCLE IMPLEMENTATION.
  METHOD DRIVE.
    IF IGNITION = 'X'.
      SPEED = SPEED + 100.
      WRITE: / 'Motorcycle speed =', SPEED.
    ENDIF.
  ENDMETHOD.
    SUPER->STOP( ).
    IGNITION = ' '.
  ENDMETHOD.
ENDCLASS.

DATA: BIKE1 TYPE REF TO C_BIKE,
      BIKE2 TYPE REF TO C_BIKE.

START-OF-SELECTION.

  CREATE OBJECT: BIKE1 TYPE C_BICYCLE,
                 BIKE2 TYPE C_MOTORCYCLE.

  BIKE1->DRIVE( ).
  BIKE2->DRIVE( ).
  ...
  BIKE1->STOP( ).
  BIKE2->STOP( ).

In this example, an abstract class C_BIKE is defined with an abstract method DRIVE and a concrete method STOP. The class is a superclass with two superclasses C_BICYCLE and C_MOTORCYCLE. C_BICYCLE implements the method DRIVE as final and inherits the method STOP without redefining it. C_MOTORCYCLE implements the method DRIVE and redefines the method STOP, both as final. C_MOTORCYCLE inherits the functions of the superclass by calling it using the pseudo-reference SUPER-> and extending the method.
Two reference variables are declared with reference to the abstract superclass C_BIKE. The reference of these variables can point to instances of the subclasses. The references of these variables can point to instances of the subclasses. Such instances are created with the TYPE addition to the statement.

Interface Parameters and Exceptions

Addition 4 to 9 of the METHODS statement define the method interface, which consists of interface parameters for passing values and exceptions that can be triggered in the method.

The interface parameters (additions 4 to 7) are created as local data of the method. If an interface parameter has the same name as an attribute of the class, this parameter obscures the class attribute in the method. You specify the attributes of the interface parameter in the interface definition.

The interface parameters including their attributes are also called
the signature of the method.

Note

You specify the interface parameter attributes using the following additions:

REFERENCE and VALUE for passing references and values
TYPE and LIKE for defining the type
OPTIONAL and DEFAULT for optional parameters

Addition 4

Effect

Defines the input parameters (IMPORTING parameters) of the method meth. All non-optional IMPORTING parameters must be passed to the method when the method is called.

If all input parameters are optional, you can use the addition PREFERRED PARAMETER to define one of the parameters pi as preference parameter. If the method is called using the syntax meth( f ), this preference parameter is then filled with the actual parameter f. Using this addition, you can add further optional parameters to methods with only one optional parameter without invalidating such method calls.

Note

An IMPORTING parameter transferred by reference cannot be changed in the method

Addition 5

... EXPORTING
           [VALUE(|REFERENCE(]p1[)] TYPE type | LIKE f
           ...
           [VALUE(|REFERENCE(]pn[)] TYPE type | LIKE f

Effect

Defines the output parameters (EXPORTING parameters) of the method meth. The EXPORTING parameters are passed back to the caller at the end of the method.

Note

If you use EXPORTING parameters, you cannot also use a RETURNING parameter.

Addition 6

Effect

Defines the input/output parameters (CHANGING parameters) of the method meth. The CHANGING parameters are passed to the method when it is called, and then passed back to the caller at the end of the method.

Note

If you use CHANGING parameters, you cannot also
use a RETURNING parameter.

Addition 7

... RETURNING VALUE(p) TYPE type | LIKE f

Effect

Defines a return code (RETURNING parameter) for the method meth. The RETURNING parameter is a single value that is passed to the called after the method has finished processing. It must be passed as a value. Methods with a return code are known as functional methods and can be called as operands in expressions (see CALL METHOD).

Notes

RETURNING parameters must be typed completely. Generic types such as ANY or STANDARD TABLE are not allowed.
If you call a functional method using CALL METHOD, RETURNING parameters are transferred to the caller in the same way as with an assignment ( MOVE). You must be able to convert the data type of the type specification into the data type of the actual parameter.
With a functional call, the type specification defines the data type of the operand.
If you use a RETURNING parameter, you cannot also use a EXPORTING- or CHANGING parameter.

Addition 8

... RAISING cx1 ... cxn

Effect

The addition you can use for the definition of METHODS, FORM and FUNCTION informs the calling program which class-based exceptions can occur.

After RAISING, you therefore list the exception classes whose exceptions may occur and which cannot be caught locally within the procedure. You may only specify classes of the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK. It is possible to specify superclasses to declare groups of exceptions in a simple manner. Since the order of the exceptions is important to the CATCH clause, you must specify the exception classes according to their inheritance hierarchy even if you declare them in ascending order.

If the interface is violated at runtime for exceptions of the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK - that is, an exception of this type leaves a procedure and the exception was not defined in the RAISING clause - the system triggers an exception of the class CX_SY_NO_HANDLER and stores a reference to the original exception in the attribute PREVIOUS. (Any handler for such an exception then does not catch the original exception but instead a programming error in the procedure called.)

The addition may only be used for the definition of METHODS and FUNCTIONS if the addition EXCEPTIONS (for exceptions that are not class-based) is not used simultaneously. Also, using the RAISING addition within the procedure defined that way means the following restrictions:

Catchable runtime errors can then only be caught using TRY ... CATCH and the corresponding exception classes for the runtime error, but not using CATCH SYSTEM-EXCEPTIONS.
You can no longer use the command RAISE to trigger exceptions that are not class-based.

Addition 9

... EXCEPTIONS p1 ... pn

Effect

Defines non class-based exceptions of the method meth. You can only use this addition if you do not use the addition RAISING for class-based exceptions. The non class-based exceptions can be triggered in the method using the statements RAISE and MESSAGE RAISING. You cannot trigger class-based exceptions using RAISE EXCEPTION if you already use non class-based exceptions.

You should no longer use this addition for methods. Use class-based exceptions instead.

Example

TYPE-POOLS BIKES.
CLASS C_BICYCLE DEFINITION.
  PUBLIC SECTION.
    DATA COLOR TYPE BIKES_COLOR.
    METHODS: DRIVE,
             STOP,
             CHANGE_GEAR IMPORTING CHANGE_TO TYPE C
                         EXPORTING GEAR TYPE I.
  PRIVATE SECTION.
    DATA: SPEED TYPE I,
          GEAR  TYPE  I VALUE 1.
ENDCLASS.

CLASS C_BICYCLE IMPLEMENTATION.
  METHOD DRIVE.
    SPEED = SPEED  + GEAR * 10.
  ENDMETHOD.

  METHOD STOP.
      SPEED = 0.
  ENDMETHOD.
  METHOD CHANGE_GEAR.
    GEAR = ME->GEAR.
    IF CHANGE_TO = '+'.
      GEAR = GEAR + 1.
    ELSEIF CHANGE_TO = '-'.
      GEAR = GEAR - 1.
    ENDIF.
    ME->GEAR = GEAR.
  ENDMETHOD.
ENDCLASS.

DATA GEAR_STATUS TYPE I.

DATA: MYBIKE1 TYPE REF TO C_BICYCLE,
      MYBIKE2 TYPE REF TO C_BICYCLE.

START-OF-SELECTION.

CREATE OBJECT MYBIKE1.
MYBIKE1->COLOR = 'Blue'.

CREATE OBJECT MYBIKE2.
MYBIKE2->COLOR = 'Red'.

MYBIKE1->CHANGE_GEAR( EXPORTING CHANGE_TO = '+'
                      IMPORTING GEAR = GEAR_STATUS ).
MYBIKE1->DRIVE( ).
MYBIKE2->DRIVE( ).
MYBIKE1->STOP( ).

This example shows some methods being declared, implememented, and called.

Variant 2

METHODS meth FOR EVENT evt OF cif.

Extras:

1. ... ABSTRACT

2. ... FINAL
4. ... IMPORTING p1 ... pn

Effect

This variant defines an instance method as a handling method for an event evt of class or interface cif. The event may also have been declared in a superclass or a component interface of cif.

You can register a handler method exclusively for the event evt using SET HANDLER. You can call handler methods either using an event ( RAISE EVENT evt) or as a normal method (CALL METHOD).

Addition 1

... ABSTRACT

Effect

As for variant 1.

Addition 2

... FINAL

Effect

As for variant 1.

Addition 3

... IMPORTING p1 ... pn

Effect

Defines the interface of handler method. The handler method interface consists of a list of IMPORTING parameters. You can only use parameters from the definition of the event interface. An event interface only EXPORTING parameters and is defined in the declaration of the event evt using the statement EVENTS. The parameter attributes are also specified when the event is defined and passed from the handler method. As well as the explicitly defined parameters of the event interface you can also use the implicit parameter SENDER as an IMPORTING parameter.

You pass the IMPORTING parameters to the handler method when it is triggered using RAISE EVENT. The IMPORTING list does not need to contain all the parameters of the AB>EXPORTING list of the EVENTS statement. The handler method determines which event parameters it wants to handle.

If the SENDER is listed, the handler method automatically receives a reference to the trigger object from the statement RAISE EVENT. In this way, the handler method can also access the trigger. Note that the type of the reference variable is not necessarily the class of the sending object. The type of the reference variable SENDER refers to exactly the class or interface cif that is listed in the statement METHODS after HANDLER OF. Handler methods for static events cannot contain the SENDER parameter.

Note

Similarly to normal methods, you define handler methods in subclasses using the REDEFINITION addition. For the redefinition you must not specify the FOR EVENT OF addition.