Ansicht
Dokumentation

ABENCLASS_SIZE_GUIDL - CLASS SIZE GUIDL

CPI1466 during Backup   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Klassengröße

Unter der Klassengröße verstehen wir die Anzahl der Komponenten (Attribute, Methoden, Ereignisse) einer Klasse. Durch den ABAP Compiler ist eine maximale Anzahl von 65.536 Komponenten vorgegeben, wobei der Gesamtspeicherverbrauch von statischen Attributen, Instanzattributen und Konstanten auf jeweils 500 Kilobytes beschränkt ist. Im Fall tiefer Datenobjekte (Tabellen, Strings und Datenreferenzen) zählt hierbei nur die feste Größe der Referenz, nicht die variable Größe des referenzierten Datenobjektes.

Vernünftige Klassengröße einhalten

Sorgen Sie dafür, dass Klassen und Interfaces nicht übermäßig viele Attribute, Methoden und Ereignisse enthalten. Die enthaltenen Komponenten müssen spezifisch für die Klasse sein und dürfen keine zu unterschiedlichen Aufgaben erfüllen. Analoges gilt für Funktionsgruppen.

Komplexität spielt sich nicht nur auf der Ebene von Prozedurimplementierungen ab. Auch die Anzahl der zu betrachtenden Prozeduren und der von ihnen bearbeiteten Daten ist für die Nachvollziehbarkeit von Quelltext erheblich.

Eine Klasse, ein Interface oder, wo noch benötigt, eine Funktionsgruppe soll nicht als ein Container für beliebige Funktionalität missverstanden werden. (Funktionsgruppen spielen in diesem Sinn die gleiche Rolle wie abstrakte finale Klassen, von denen keine Instanzen erzeugt werden können. Die Funktionsbausteine entsprechen hier statischen öffentlichen Methoden und die globalen Daten den privaten statischen Attributen.) Vielmehr handelt es sich um die Abstraktion eines bestimmten Sachverhalts oder eines Objektes aus dem wirklichen Leben. Gerade diese Modularisierung eines komplexen Problems in Objekte überschaubarer Größe erleichtert das Verständnis des Codes. Dazu müssen aber auch die Klassen und Interfaces entsprechend geschnitten sein und jeweils überschaubare und leicht zu erfassende Funktionalität abdecken.

Wenn eine Klasse oder ein Interface sehr viele Attribute und Methoden umfasst, ist dies ganz offenbar nicht der Fall. Analoges gilt für die Anzahl von Funktionsbausteinen einer Funktionsgruppe bezüglich der Verwendung von Funktionsgruppen. Voluminöse Klassen, Interfaces oder Funktionsgruppen bieten entweder zu heterogene Funktionalität an, oder sie sind umgekehrt hoch spezialisiert, was ihre Wiederverwendbarkeit unnötig einschränkt.

Neben der hohen Komplexität, welche die Wartbarkeit von voluminösen Klassen und Funktionsgruppen vermindert, ist ein weiterer, technischer Aspekt zu beachten: Allein die Verwendung eines kleinen Teils der angebotenen Funktionalität führt zum Laden der gesamten Klasse oder Funktionsgruppe in den Sitzungsspeicher, was sich ungünstig auf die Speicherausnutzung auswirkt.

Hinweis

Mehrere nicht zu große Prozeduren mit klar abgegrenzten Aufgaben sind gegenüber wenigen großen Prozeduren zu bevorzugen. Andererseits sollen Klassen nicht zu viele Methoden enthalten. Aus diesen beiden Regeln erwächst dennoch kein Widerspruch, wenn die Prozeduren nicht zu klein werden und sinnvoll in unterschiedlichen Klassen mit eng begrenztem Aufgabenfeld gruppiert sind. Dabei können auch sehr spezialisierte Klassen entstehen, die keine globale Sichtbarkeit erfordern.

Funktionalität, die nur innerhalb einer globalen Klasse, Funktionsgruppe oder eines sonstigen Programms benötigt wird, soll daher in lokalen Klassen gekapselt werden. (Sämtliche Funktionalität von Function-Pools, Subroutinen-Pools und ausführbaren Programmen soll ohnehin in lokalen Klassen implementiert werden.) Ein Beispiel für eine solche in sich geschlossene Funktionalität ist die Anzeigelogik für klassische Dynpros innerhalb einer Funktionsgruppe.) Eine sinnvolle Wiederverwendung der Klassen, welche die Dynpros ansteuern, ist außerhalb der Funktionsgruppe nicht denkbar. Daher sind lokale Klassen hier das Mittel der Wahl.

Auch für globale Klassen ist ein solches Vorgehen sinnvoll. Durch Auslagerung hoch spezialisierter Funktionalität in kleinere lokale Klassen wird die Methodenanzahl der globalen Klasse verringert, was die Übersichtlichkeit verbessert und die Klasse leichter wartbar macht. Beim Einsatz lokaler Klassen innerhalb von globalen Klassen ist dabei auf eine geeignete Platzierung zu achten, um unnötige Abhängigkeitsbeziehungen zu vermeiden).

General Data in Customer Master   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 5325 Date: 20240523 Time: 155240     sap01-206 ( 120 ms )