Transaktion SE24 (Class Builder)

Siehe Object Navigator (Transaktion SE80).

Zentral für die Pflege von globalen Klassen ist die Transaktion SE24 (Class Builder).

Der Class Builder mit seinen Methoden ist in einer Funktionsgruppe (Hauptprogramm) mit Funktionsbausteinen (Includes vom Hauptprogramm) vergleichbar. Die Methoden einer Klasse sind jedoch deutlich flexibler und übersichtlicher als die Funktionsbausteine einer Funktionsgruppe.

Class Builder über Transaktion SE80

Object Navigator (Transaktion SE80)
Der Class Builder ist auch in die Transaktion SE80 eingebettet und daher braucht die Transaktion SE24 meist nicht als eigenständige Transaktion benutzt werden. Die Funktionen der Klassenverwaltung über SE24 und die Funktionen der Klassenverwaltung als Teil der SE80 sind fast identisch. Da die SE80 alles bietet, was die SE24 auch bietet und noch zusätzliche Funktionen hat und zudem die Integration in die Verwaltung vieler weiterer Entwicklungsobjekte bietet, ist die Nutzung der Transaktion SE80 zu empfehlen.

Aufruf einer Klasse

Der erste Schritt ist in der Einstiegsmaske die Selektion einer Klasse oder eines Interfaces. Es kann eine Wertehilfe aufgerufen werden, wo nach Klassen oder Interfaces gesucht werden kann. Hier wird die Klasse ZBA_CL_PRINT_DATA_ST aufgerufen.

Registerkarten Class Builder

Im Detailbild des Class Builders gibt es verschiedene Registerkarten.

Registerkarte Eigenschaften

Hier werden bei der Anlage der Klasse meist die Defaultwerte übernommen.
Es könnte an dieser Stelle auch eine Standardnachrichtenklasse eingetragen werden, damit man in Nachrichtenaufrufen diese Nachrichtenklasse nicht jedes mal eingeben muss. Das ist aber nur sinnvoll, wenn (fast) immer die Messages/Nachrichten aus der gleichen Nachrichtenklasse kommen. Sonst verwirrt es beim Lesen des Codings, wenn gelegentlich bei der Messageausgabe die Nachrichtenklasse nicht mitgegeben wird. In aller Regel sollte man die Nachrichtenklasse hier leer lassen.

Registerkarte Interfaces

Interfaces erleichtern die Verwendung von Methoden. Interfaces beschreiben die Parameter von Methoden, die dann in der Klasse genutzt werden können, die die Interfaces eingetragen hat.
Die Implementierung der Methoden muss jedoch in der Klasse gemacht werden.
Unter der Registerkarte "Methode" erscheint die Schnittstelle der Interfacemethoden in schwarzer Schrift in der Form

Interfacename~Methodenname

Registerkarte Friends

Standardmäßig können Benutzer einer Klasse nur auf die PUBLIC-Komponenten dieser Klasse zugreifen. Das Konzept der Friendsermöglicht es ausdrücklich genannten anderen Klassen (Friends) den Zugriff auf die PROTECTED- und PRIVATE-Komponenten einer Klasse zu gewähren.
Diese Registerkarte wird in aller Regel nicht nicht benötigt und ist nicht gefüllt.

Weiter führende Informationen in der SAP-Hilfe.

Registerkarte Attribute

Attribute sind die Variablen, die innerhalb der Klasse gespeichert werden (Art = Static Attribute) oder innerhalb der Instanz der Klasse (Art = Instance Attribute) gespeichert werden.
Bei der Deklaration von internen Tabellen ist nicht die Bezeichnung "type table" möglich. Es muss dann ein Tabellentyp angelegt werden im Dictionary oder lokal in der Klasse durch direkte Typeingabe.
Für die Benennung der Variablen ist üblich
- MV = Instanzvariable (M = Member, Instance)
- MS = Instanzstruktur
- MT = Instanztabelle
- MO = Instanz auf ein anderes Objekt
- Die Statischen Variablen beginnen mit "S". Besser sollte man aber etwas anderes als das Präfix "SS" für eine statische Struktur wählen ;-).
Die Attribute lassen sich auch von außerhalb der Klasse aufrufen, sofern das Attribut Public ist.
Es lassen sich auch Attribute definieren, die auf andere Klassen referenzieren und sich so ansprechen lassen.

Registerkarte Methoden

Diese Registerkarte "Methoden" ist elementar wichtig für die Klasse. Eine Klasse ohne Methoden macht in aller Regel keinen Sinn.
Methodennamen sollten mit einem Verb beginnen und englischsprachig sein, wie z. B. hier "read_student_details".
Genau wie bei Attributen gibt es Klassenmethoden (Art = Static) und Instanzmethoden (Art = Instance).
Ebenso wie bei Attributen gibt es die Sichtbarkeit Public (Aufrufbarkeit außerhalb der Klasse), Protected (Aufruf auch durch vererbte Klassen) oder Private (Aufrufbarkeit nur innerhalb der Klasse).

Die Methoden haben gewöhnlich Parameter (Schaltfläche "Parameter"), wenn auch nicht zwingend. Die Parameter können maximal sein
- Import-Parameter (nur Import) (Präfixnamen IV, IS oder IT)
- Changing-Parameter (Import und Export) (Präfix CV, CS oder CT)
- Export-Parameter (nur Export) (Namen EV, ES oder ET)
- Receiving-Parameter (Maximal 1 Receiving-Parameter ist erlaubt. Sehr ähnlich dem Exportparameter, aber ein Receiving-Parameter kann vom Aufrufer einfach verarbeitet werden kann im Vergleich zum Export-Parameter) (Präfix RV, RS oder RV)
- Einen Tables-Parameter wie bei Funktionsbausteinen oder Form-Routinen gibt es bei Methoden nicht. Dieser Perameter ist auch für Funktionsbausteine und Form-Routinen obsolet und nur weiterhhin zulässig aufgrund der Notwendigkeit der Lauffähigkeit vom alten Coding, der sonst umgeschrieben werden müsste. Nach Möglichkeit sollte man auch bei Funktionsbausteinen und Form-Routinen diesen Parameter nicht mehr verwenden, da bei Tables-Parameter unklar ist, ob dieser Parameter nur eine interne Tabelle importiert, ändert oder lediglich exportiert. Das ist für das Verständnis dieses Parameters sehr ungünstig.
Hat man mit einem Doppelklick die Methode aufgerufen, kann man das Coding editieren und über die Schaltfläche "Signatur" sieht man parallel auch die Parameter der Methode. Es ist sehr empfehlenswert die Signatur der Methoden immer aktiv zu haben.
In das Coding der Methode werden die Parameter leider nicht wie beim Funktionsbaustein als Kommentar eingefügt. Das ist schade, da man bei einem Funktionsbaustein so beim Debuggen immer noch die Parameter des Funktionsbausteins jederzeit im Blick haben kann.
Hat die Klasse von einer Oberklasse Methoden geerbt

Registerkarte Typen

Hier können lokale Typen definiert werden, die dann nicht im Dictionary angelegt werden müssen. Das bietet sich immer dann, wenn z. B. eine Struktur definitiv nur in der Klasse benutzt wird und nicht in anderen Programmen, Funktionsbausteinen oder Klassen.

Die lokalen Typen können in der Klasse genauso genutzt werden wie Dictionary-Objekte zur Typisierung von Variablen und Konstanten.

Über die Schaltfläche "Direkte Typangabe" kann man in eine Quellcodeansicht wechseln und hier frei lokale Typen anlegen.

Registerkarte Aliase

Hier können Methoden oder Attribute aufgeführt werden und mit einem Stellvertreternamen (Alias) gekennzeichnet werden. Die Methoden oder Attribute können dann mit dem Aliasnamen angesprochen werden. Der Alias sollte dann kurz und sprechend sein.

Verberbung von Klassen

Bei der "Superklasse", bzw. "Oberklasse" (in neueren Releases) kann eine Oberklasse eingetragen werden. Bei der Oberklasse darf das Merkmal "Final" nicht gesetzt sein, sonst ist eine Vererbung von dieser Klasse nicht erlaubt.
Methoden können von der Oberklasse geerbert werden und 1 zu 1 so genutzt werden, aber auch redefiniert werden. Bei der Redefinition bleiben die Parameter erhalten von der geerbten Methode, aber das Coding kann verändert werden in der erbenden Klasse. Eine Redefinition einer Methoden kann auch wieder entfernt werden. Auch bei redefinierten Methoden kann auf die ursprüngliche Methode der Oberklasse zugegriffen werden mit "SUPER‐>Methodenname()". In der Unterklasse können auch neue Methoden ergänzt werden, die in der Oberklasse nicht vorhanden sind.
Hier u. a. hat die objektorientierte Programmierung auch ihre Vorteile gegenüber Funktionsbausteinen oder Form-Routinen wo Verberbung nicht vorgesehen ist. Bei Funktionsbausteinen oder Form-Routinen würde man die Programmeinheiten parametrisieren, damit sie in Abhängigkeit der Parameter unterschiedlich sich verhalten oder die Programmeinheiten kopieren und dann anpassen. Bei der Vererbung vermeidet man redundantes Coding.
Vererbte Methoden werden in blauer Schrift dargestellt, um das Coding leicht unterscheiden zu können, ob es geerbt ist oder in der eigenen Klasse geschrieben (schwarze Schrift) ist.
Hier erbt die SAP-Standardklasse CL_GUI_ALV_GRID von der Oberklasse CL_GUI_ALV_GRID_BASE.

Konstrukturen oder Klasse

Es gibt drei verschiedene Konstruktoren in der Klasse. Diese 3 Methoden können maximal implementiert werden.

Klassen-Konstruktur

Einmalig bei der Instanziierung einer Klasse wird der Klassenkonstruktor ausgeführt.

Class-constructor.

Instanz-Konstruktor

Bei jeder Instanz der Klasse wird der Instanz-Konstruktur ausgeführt.

Constructor.

Destruktor

Bei der Zerstörung eines Objektes der Klasse wird der Destruktur aufgerufen.

Destructor.

Suchfunktion

Über den Button in der Symbolleiste vom Class Builder wird die globale Suchfunktion in der Klasse aufgerufen

Es wird entweder global in der Klasse gesucht oder sofern die Suche aus einer Methode heraus ausgerufen wurde, kann man auch in einer Methode suchen. Hier im Beispiel erfolgte die Suche aus dem Konstruktur der Klasse heraus

Der String IT_SELTOPT_BUDAT wird sowohl in den Schnittstellen der Klasse/Methoden als auch im Coding der Methoden gesucht und angezeigt

Ein Klick auf eine Fundstelle ruft die entsprechende Methode auf

Klassendokumentation

Klassendokumentation/Dokumentenpflege

Quelltextbasiert

Eine interessante Funktion im Class Builder ist es, wenn man sich das Coding der Klasse im Quelltext anzeigen lässt mit der Schaltfläche oder über das Kontextmenü "Wechsel zu quelltextbas. Class Builder“
Im Quelltext lässt sich die gesamte Klasse z. B. leicht sichern über Copy&Paste in einer Textdatei und so mit sehr wenig Aufwand in einem anderen SAP-System wieder anlegen. Eine andere Anwendung wäre die Anlage einer globale Klasse, die auf dem Coding einer lokalen Klasse beruht. Hier kann das Coding dann mit Copy&Paste übernomnmen werden in der Quelltextansicht. Genauso umgekehrt könnte man das Coding einer globalen Klasse so leicht als lokale Klasse in einem Programm übernehmen.

Zurück in die Formularansicht des Class Builders kommt man mit der Schaltfläche .

Signatur

Sehr praktisch ist im Class Builder im Gegensatz zum Function Builder (SE37), dass bei der Pflege des Codings einer Methode die Schnittstelle (Signatur) ständig sichtbar ist (sofern eingeblendet).

Über die Schaltfläche lässt sich die Signatur einblenden, bzw. ausblenden. In aller Regel macht es Sinn sie ständig eingeblendet zu haben.

Transportobjekte der Klasse

Die Entwicklungsobjekte einer Klasse lassen sich unterteilen in

Implementierung einer Methode

Der Objektname setzt sich aus dem Namen der Klasse und dem Namen der Methode zusammen.
Jede Methode der Klasse hat somit hier ein eigenes Transportobjekt

Programm-ID = LIMU
Objekttyp   = METH
Objektname  = Z_CL_FORMULARE       TESTMETHODE

Definitionen der Klasse

Der Objekttyp unterscheidet sich hier in “CPUB” (Public Methoden), in “CPRO” (Protected Methoden) und in “CPRI” (Private Methoden)

Public

Programm-ID = LIMU
Objekttyp   = CPUB
Objektname  = Z_CL_FORMULARE

Protected

Programm-ID = LIMU
Objekttyp   = CPRO
Objektname  = Z_CL_FORMULARE

Private

Programm-ID = LIMU
Objekttyp   = CPRI
Objektname  = Z_CL_FORMULARE

Die Gesamtklasse

Alle Definitionen und Implementierungen einer Klasse werden transportiert. Dies kann sehr nützlich sein bei einem Transport, um nicht Gefahr zu laufen, dass Teile einer Klasse in verschiedenen Transportauftragen verstreut sind und es dann im Produktiv zum Syntaxfehler in der Klasse kommt, aufgrund von fehlenden Objekten.
So ist es im Projekt zu einem Syntaxfehler in einer zentralen Formularklasse gekommen und in Folge konnte für kurze Zeit kein Formular mehr ausgegeben werden. Man steht dann als verantwortlicher Entwickler mehr im Mittelpunkt als man sich das wünschen würde.

Programm-ID = R3TR
Objekttyp   = CLAS
Objektname  = Z_CL_FORMULARE

Web-Links