SAP MODULARIZATION - Guide

Get Example source ABAP code based on a different SAP table
  SAP Help

GUIDELINE 5.2

Modularization

ABAP_BACKGROUND
The main programming model that was propagated before the implementation of ABAP Objects was structured programming:

In this model, the programs are split into procedures as appropriate.

Sequences, branches, and loops are the only control structures permitted.
The implementation of object-oriented programming languages such as ABAP Objects does not make structured programming obsolete. Object-oriented programming is based on the structured programming and enhances and supplements it.
With regard to ABAP, you must note that ABAP is still a programming language of the fourth generation (4GL) that has been developed especially for application programming in the SAP environment, that is, for mass data processing in business applications. Therefore, ABAP includes significantly more language elements than an elementary programming language in which the more complex functionality is usually stored in libraries. This ranges from simple statements for string processing, which are provided as methods of string classes in other object-oriented languages such as Java, to the processing of complex mass data objects, such as internal tables, to very complex statements for operating interfaces such as Open SQL or for calling data transformations (XML), for which other languages have entire class hierarchies.
As already mentioned, the performance of the ABAP language is therefore optimized mainly for the execution of its complex statements for mass data processing and less for the individual method call.

ABAP_RULE
Modularize Rather than Atomize
Modularize your program in classes, but not to the extent that there is an individual method for every trivial function. Methods that consist of only one or just a few statements should be an exception in ABAP and not the rule.

ABAP_DETAILS
You should only use methods of ABAP Objects for the implementation of functions; there are very good reasons for this. But ABAP remains ABAP, and the good reasons for using a well-structured program are not invalidated by the implementation of ABAP Objects. Indeed, the ABAP language elements proven and tested in so many application cases are still valid today, are undergoing continuously development, and should be used in their present form in ABAP Objects as well.
An already well-structured classical ABAP program, for instance a function group that fulfills a specific task and is modularized using subroutines, should therefore be transferable to a class without any major changes to the implementation, whereby it is provided with all the additional benefits of ABAP Objects.
However, the modularization at the level of a few single statements is and will remain untypical for ABAP. On the one hand this is because of performance reasons, because the costs for the method call must remain low in comparison to the costs for executing the implementation. For example, instead of providing the get_attribute methods typical for other object-oriented languages that only set their return value to the value of an attribute attribute, you should use public READ-ONLY attributes in ABAP. (If the read access to an attribute is linked with further actions, for example, authorization checks, get_attribute methods are appropriate, of course.) On the other hand, virtually all non-fundamental statements of ABAP (all language elements that do not have any equivalent in an elementary language like Java) already play the same role that the methods of system classes assume in other programming languages. The use of such a statement corresponds to a method call, and another encapsulation is usually not necessary.
Also, for legibility and maintainability reasons, a method with a reasonable size is preferable to splitting into atomic units, that is, into methods with only one or two statements.

Exception
Procedures that encapsulate nothing but the call of another procedure are an exception. A single procedure call represents the implementation of an entire procedure. This applies in particular to function modules and subroutines, which can only be created in exceptional cases anyway. They should include exactly one method call, which delegates the implementation to ABAP Objects. In this case, the improved security through the stricter checks in ABAP Objects outweighs the disadvantages of very short procedures.

Bad example
The following source code shows the rudimentary implementation of a string class in ABAP Objects. The methods of this class each contain only a single statement. A user must generate objects of the class and call the methods to handle the strings. CLASS cl_string DEFINITION PUBLIC.
PUBLIC SECTION.
METHODS:
constructor IMPORTING value TYPE string OPTIONAL,
set_string IMPORTING value TYPE string,
get_string RETURNING VALUE(value) TYPE string,
shift_left IMPORTING places TYPE i,
shift_right IMPORTING places TYPE i,
...
PRIVATE SECTION.
DATA string TYPE string.
ENDCLASS. CLASS cl_string IMPLEMENTATION.
METHOD constructor.
string = value.
ENDMETHOD.
METHOD set_string.
string = value.
ENDMETHOD.
METHOD get_string.
value = string.
ENDMETHOD.
METHOD shift_left.
SHIFT string LEFT BY places PLACES.
ENDMETHOD.
METHOD shift_right.
SHIFT string RIGHT BY places PLACES.
ENDMETHOD.
...
ENDCLASS.
... CLASS application IMPLEMENTATION.
...
METHOD do_something.
DATA string TYPE REF TO cl_string.
CREATE OBJECT string EXPORTING value = 'abcde'.
...
string->shift_left( ... ).
...
ENDMETHOD.
...
ENDCLASS.

Good example
The following source code shows the handling of strings typical to ABAP. A method directly declares a data object of type string and directly uses the corresponding ABAP statements for processing. CLASS application IMPLEMENTATION.
...
METHOD do_something.
DATA string TYPE string.
...
SHIFT string LEFT BY ... PLACES.
...
ENDMETHOD.
...
ENDCLASS.
There is a corresponding built-in function for almost every string processing statement. They can also be used in operand positions, negating another reason for the encapsulation of statements in methods. The SHIFT LEFT statement in this example can be replaced as follows, whereas shift_left is a built-in function: string = shift_left( val = string places = ... ).