Show TOC Anfang des Inhaltsbereichs

Class- und Interface-Pools  Dokument im Navigationsbaum lokalisieren

Dieser Abschnitt geht etwas näher auf den Aufbau und die Besonderheiten von Class- und Interface-Pools für globale Klassen ein.

Globale Klassen und Interfaces

Klassen und Interfaces sind sogenannte Objekttypen. Die Definition von Klassen und Interfaces erfolgt entweder global im Repository oder lokal in einem ABAP-Programm. Bei der globalen Definition dienen spezielle ABAP-Programme namens Class-Pools oder Interface-Pools vom Typ K oder J als Container für Klassen und Interfaces. Jeder Class- bzw. Interface-Pool enthält die Definition genau einer Klasse bzw. eines Interfaces. Die Class- und Interface-Pools werden beim Anlegen von Klassen und Interfaces mit dem Werkzeug Class Builder der ABAP Workbench automatisch generiert.

Ein Class-Pool ist in etwa vergleichbar mit einem Modulpool oder einer Funktionsgruppe. Er enthält sowohl deklarative als auch ausführbare ABAP-Anweisungen, kann aber nicht eigenständig gestartet werden. Das Laufzeitsystem kann bei einer Anforderung durch die Anweisung CREATE OBJECT Laufzeitinstanzen (Objekte) der Klasse erzeugen, welche die Anweisungen des Class-Pools ausführen.

Ein Interface-Pool enthält keine ausführbaren Anweisungen, sondern dient als Ablage für die Definition eines Interfaces. Bei der Implementierung des Interfaces in eine Klasse, wird die Definition des Interfaces implizit in die Definition der Klasse eingebunden.

Aufbau eines Class-Pools

Der Aufbau eines Class-Pools ist wie folgt:

Diese Grafik wird im zugehörigen Text erklärt

Ein Class-Pool enthält einen Definitionsteil für typdeklarative Anweisungen, den Deklarationsteil und den Implementationsteil der Klasse.

Unterschiede zu anderen ABAP-Programmen

Class-Pools unterscheiden sich in folgenden Punkten von anderen ABAP-Programmen:

·        ABAP-Programme, wie ausführbare Programme, Modul-Pools oder Funktionsbausteine, haben in der Regel einen Deklarationsteil, in dem die globalen Daten des Programms definiert werden. Diese Daten sind in allen Verarbeitungsblöcken des Programms sichtbar. Class-Pools haben statt dessen einen  Definitionsteil, in dem nur Daten- und Objekttypen definiert werden können, aber keine Datenobjekte und keine Feldsymbole. Die im Definitionsteil eines Class-Pools definierten Typen sind nur im Implementierungsteil der globalen Klasse sichtbar.

·        Die einzigen erlaubten Verarbeitungsblöcke sind der Deklarationsteil und der Implementierungsteil der globalen Klasse. Im Implementierungsteil können nur die im Deklarationsteil deklarierten Methoden der globalen Klasse implementiert werden. Alle übrigen in ABAP möglichen Verarbeitungsblöcke, also Dialogmodule, Ereignisblöcke, Unterprogramme und Funktionsbausteine sind in einem Class-Pool nicht erlaubt.

·        Die Verarbeitungsblöcke von Class-Pools werden nicht von der ABAP-Laufzeitumgebung gesteuert. In Class-Pools treten keine Ereignisse auf und es können keine Dialogmodule oder Prozeduren von außen aufgerufen werden. Ein Class-Pool dient ausschließlich der Programmierung einer Klasse. Der einzige Zugang zu den Daten und der Funktionalität der Klasse erfolgt durch die Schnittstelle der Klasse.

·        Da in Class-Pools keine Ereignisse auftreten und keine Dialogmodule aufgerufen werden können, ist die in den übrigen ABAP-Programmen übliche Bildschirmverarbeitung nicht möglich. Zu einer Klasse können keine Listen- und Selektionsbilder definiert werden, da sie nicht auf die entsprechenden Ereignisse reagieren kann. Für Dynpros ist eine Anbindung an Klassen vorgesehen. Statt Dialogmodule sollen dann Methoden der Klasse von der Dynpro-Ablauflogik aufgerufen werden.

Lokale Klassen in Class-Pools

Die im Definitionsteil eines Class-Pools definierten Klassen und Interfaces sind von außen nicht sichtbar. Sie spielen im Class-Pool eine ähnliche Rolle wie lokale Klassen und Interfaces in sonstigen ABAP-Programmen. Die lokalen Klassen können ausschließlich in den Methoden der globalen Klasse instanziert werden. Da in Class-Pools keine Unterprogramme erlaubt sind, sind die lokalen Klassen die einzigen Modularisierungseinheiten, in die innerhalb des Class-Pools Funktionalität der globalen Klasse ausgelagert werden kann. Die lokalen Klassen spielen für die globale Klasse in etwa die gleiche Rolle wie Unterprogramme in Funktionsgruppen, mit dem großen Unterschied, dass sie von außen nicht sichtbar sind.

 

Ende des Inhaltsbereichs