Ansicht
Dokumentation

ABENMODULARIZATION_GUIDL - MODULARIZATION GUIDL

ABENMODULARIZATION_GUIDL - MODULARIZATION GUIDL

BAL Application Log Documentation   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Modularisierung

Das vor der Einführung von ABAP Objects im Wesentlichen propagierte Programmiermodell war das der strukturierten Programmierung:

  • Hierbei werden Programme sinnvoll in Prozeduren zerlegt.
  • Sequenzen, Verzweigungen und Schleifen sind die einzigen erlaubten Kontrollstrukturen.

Die Einführung objektorientierter Programmiersprachen wie ABAP Objects macht die strukturierte Programmierung nicht obsolet. Die objektorientierte Programmierung baut auf der strukturierten Programmierung auf und erweitert oder ergänzt diese.

In Bezug auf ABAP ist dabei zu beachten, dass ABAP nach wie vor eine Programmiersprache der vierten Generation (4GL) ist, die speziell für die Anwendungsprogrammierung im SAP-Umfeld, das heißt für die Massendatenverarbeitung in betriebswirtschaftlichen Anwendungen, entwickelt wurde. ABAP enthält deshalb wesentlich mehr Sprachelemente als eine elementare Programmiersprache, in der komplexere Funktionalität in der Regel in Bibliotheken abgelegt ist. Dies reicht von einfachen Anweisungen zur String-Verarbeitung, die in anderen objektorientierten Sprachen wie Java als Methoden von String- Klassen angeboten werden, über die Verarbeitung komplexer Massendatenobjekte wie interner Tabellen bis hin zu sehr komplexen Anweisungen zur Bedienung von Schnittstellen wie oder für Aufrufe von Datentransformationen (XML), wofür es in anderen Sprachen ganze Klassenhierarchien gibt.

Wie bereits erwähnt, ist die Performance der Sprache ABAP deshalb hauptsächlich in Bezug auf die Ausführung ihrer komplexen Anweisungen für die Massendatenverarbeitung und weniger auf den einzelnen Methodenaufruf hin optimiert.

Modularisieren anstatt zu atomisieren

Modularisieren Sie Ihr Programm so in Klassen, dass die einzelnen Methoden jeweils nicht triviale Funktionalität abdecken. Methoden, die aus nur einer oder sehr wenigen Anweisungen bestehen, sollten in ABAP eher die Ausnahme als die Regel sein.

Für die Implementierung von Funktionalität sollen nur noch Methoden von ABAP Objects benutzt werden, und es gibt genügend gute Gründe dafür. Aber ABAP bleibt ABAP und durch die Einführung von ABAP Objects sind die ebenso guten Gründe, die für ein wohl strukturiertes Programm sprechen, nicht hinfällig geworden. Stattdessen sollen die in vielfachen Anwendungsfällen bewährten ABAP-Sprachmittel, die heute noch gültig sind und auch ständig weiterentwickelt werden, in ihrer bisherigen Form auch in ABAP Objects verwendet werden.

Ein bereits wohl strukturiertes klassisches ABAP-Programm, zum Beispiel eine Funktionsgruppe, die eine bestimmte Aufgabe erfüllt und über Unterprogramme modularisiert ist, sollte damit ohne große Änderungen an der Implementierung in eine Klasse überführbar sein, wodurch ihm alle weiteren Vorteile von ABAP Objects zur Verfügung stehen.

Untypisch für ABAP ist und bleibt dagegen die Modularisierung auf der Ebene einzelner weniger Anweisungen. Dies hat zum einen Performancegründe, da die Kosten für den Aufruf der Methode im Vergleich zu den Kosten für die Ausführung der Implementierung klein bleiben müssen. Anstatt beispielsweise die für andere objektorientierte Sprachen typischen get_attribute-Methoden anzubieten, die nur ihren Rückgabewert auf den Wert eines Attributes attribute setzen, sollten in ABAP öffentliche READ-ONLY-Attribute verwendet werden. (Wenn der Lesezugriff auf ein Attribut mit weiteren Aktionen, wie zum Beispiel Berechtigungsprüfungen, verknüpft ist, sind get_attribute-Methoden natürlich angemessen.) Zum anderen spielen fast alle nicht fundamentalen Anweisungen (also alle Sprachelemente, die kein Pendant in einer elementaren Sprache wie Java haben) von ABAP bereits eine Rolle, wie sie in anderen Programmiersprachen den Methoden von Systemklassen zukommt. Die Verwendung einer solchen Anweisung entspricht sozusagen einem Methodenaufruf, und eine weitere Verschalung ist in der Regel nicht notwendig.

Schließlich ist auch aus Gründen der Lesbarkeit und Wartbarkeit eine Methode vernünftiger Größe einer Zersplitterung in atomare Einheiten, das heißt in Methoden mit nur ein bis zwei Anweisungen, vorzuziehen.

Ausnahme

Prozeduren, die nichts als den Aufruf einer anderen Prozedur verschalen, bilden hier eine Ausnahme. Ein einzelner Prozeduraufruf steht hier stellvertretend für die Implementierung einer gesamten Prozedur. Dies gilt insbesondere für Funktionsbausteine und Unterprogramme, die ohnehin nur noch in Ausnahmefällen angelegt werden dürfen. Diese sollen genau einen Methodenaufruf enthalten, der die Implementierung an ABAP Objects delegiert. Hier wiegt der damit verbundene Gewinn an Sicherheit durch die schärferen Prüfungen in ABAP Objects schwerer als die Nachteile sehr kurzer Prozeduren.

Folgender Quelltext zeigt die ansatzweise Implementierung einer String-Klasse in ABAP Objects. Die Methoden dieser Klasse enthalten alle jeweils nur eine einzige Anweisung. Ein Verwender muss zum Umgang mit Strings Objekte der Klasse erzeugen und die Methoden aufrufen.

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.

Folgender Quelltext zeigt den ABAP-typischen Umgang mit Strings. Eine Methode deklariert direkt ein Datenobjekt vom Typ string und verwendet zur Bearbeitung direkt die zugehörigen ABAP-Anweisungen.

CLASS application IMPLEMENTATION.
  ...
   METHOD do_something.
     DATA string TYPE string.
     ...
     SHIFT string LEFT BY ... PLACES.
     ...
   ENDMETHOD.
  ...
ENDCLASS.

Es gibt für fast jede String-Verarbeitungsanweisung eine entsprechende, eingebaute Funktion. Diese können auch an Operandenpositionen eingesetzt werden, sodass ein weiterer Grund für die Verschalung der Anweisungen in Methoden entfällt. Die Anweisung SHIFT LEFT im Beispiel kann wie folgt ersetzt werden, wobei shift_left eine eingebaute Funktion ist:

string = shift_left( val = string places = ... ).






RFUMSV00 - Advance Return for Tax on Sales/Purchases   General Material Data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 9301 Date: 20240523 Time: 100451     sap01-206 ( 152 ms )