Wissen aus erster Hand.

Leseprobe
Um einheitliche Objekte für eine ABAP-Anwendung zu erzeugen,
können Sie standardisierte Entwurfsmuster einsetzen. In dieser Lese-
probe stellen Ihnen die Autoren die unterschiedlichen Möglichkeiten
vor, die sich durch Entwurfsmuster für die Erzeugung von Objekten
ergeben. Darüber hinaus umfasst diese Leseprobe neben Kapitel 3
des Buches das Inhaltsverzeichnis sowie den Index.

Kapitel 3: »Erzeugungsmuster«

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

Nurgül Atilgan, Markus Straub

Entwurfsmuster in ABAP
384 Seiten, gebunden, 2. Auflage 2015
69,90 Euro, ISBN 978-3-8362-3810-6

www.sap-press.de/3881
Kapitel 3

Um einheitliche Objekte für eine Anwendung zu erzeugen,

können Sie standardisierte Entwurfsmuster einsetzen. Dazu
steht Ihnen die Gruppe der Erzeugungsmuster zur Verfü-
gung, deren Entwurfsmuster unterschiedliche klassenbasierte
oder objektbasierte Objekte erzeugen.

3 Erzeugungsmuster

Alle Entwurfsmuster, die in die Kategorie der Erzeugungsmuster ein-

geordnet sind, dienen dazu, Objekte zu erstellen. Die für die Objekt-
erzeugung notwendigen Details werden bei den Entwurfsmustern
dieser Kategorie in Klassen gekapselt. Der Vorteil dieses Verfahrens
ist, dass die Implementierung der Objekterzeugung komplett
getrennt von den zu erstellenden Objekten erfolgt. Das heißt, es
müssen keine Änderungen am Objekt selbst vorgenommen werden,
wenn ein neues Objekt erstellt wird.

Wie bereits in Abschnitt 1.1.2, »Softwaredesign mithilfe von Ent- Klassen- und
wurfsmustern«, erläutert, unterscheiden wir bei Entwurfsmustern Objektmuster

grundsätzlich zwischen zwei Varianten:

왘 Einerseits gibt es objektbasierte Entwurfsmuster, die durch objekt-

basierte Programmierung umgesetzt werden. Durch die Verwen-
dung von ABAP-Objects-Schlüsselwörtern (z. B. CREATE OBJECT
oder ab SAP NetWeaver 7.4 das Schlüsselwort NEW) werden dabei
Instanzen der Klassen erzeugt.
왘 Die zweite Variante sind Entwurfsmuster, die auf Klassenmustern
basieren. Diese werden mithilfe statischer Methoden umgesetzt.

Im Folgenden ordnen wir die in diesem Kapitel vorgestellten Muster Klassen- und
der Gruppe der Erzeugungsmuster diesen beiden Kategorien zu: objektbasierte
Erzeugungsmuster
왘 Klassenmuster
– Factory Pattern
Wie alle Erzeugungsmuster erzeugt das Factory Pattern neue
Objekte. Diese Objekte werden über Klassen anhand von

63
3 Erzeugungsmuster
Importparametern definiert. Bei diesen Klassen handelt es sich
jeweils um Ableitungen einer abstrakten Klasse. Das Entwurfs-
muster setzt dabei das Polymorphismus-Prinzip um.
– Abstract Factory Pattern
Das Abstract Factory Pattern basiert auf dem Factory Pattern. Im
Falle des Abstract Factory Patterns ist die Factory-Klasse selbst
eine abstrakte Klasse. Dies hat den Vorteil, dass die Factory-
Klasse noch flexibler und austauschbarer ist. Das Abstract Fac-
tory Pattern erzeugt keine konkreten Objekte, sondern kon-
krete Factory-Klassen. Dies bedeutet, eine abstrakte Factory-
Klasse ist eine Factory für die konkreten Factory-Klassen. Durch
dieses Konzept lassen sich jederzeit neue Factory-Klassen inte-
grieren oder bestehende durch andere Factory-Klassen ersetzen.
왘 Objektmuster
– Builder Pattern
Beim Builder Pattern wird die Erzeugung komplexer Objekte
von der eigentlichen Repräsentation getrennt. Dadurch können
unterschiedliche Repräsentationen der Objekte erzeugt wer-
den. Diese sind immer abhängig von den Anforderungen der
jeweiligen Klassen bzw. von der Erzeugung. Dieses Entwurfs-
muster arbeitet mit unterschiedlichen Konstruktoren, die oft in
Verbindung mit Kompositum-Entwurfsmustern verwendet
werden. Das Kompositum-Entwurfsmuster wird genutzt, um
Hierarchien aus Objekten aufzubauen, die zusammen als Teile
eines Ganzen dienen. Dabei werden die Objekte zu Baumstruk-
turen zusammengesetzt.
– Prototype Pattern
Das Prototype Pattern wird zunächst mit einer vorläufigen In-
stanz eines komplexen Objekts initialisiert. Im weiteren Verlauf
wird immer das ursprüngliche Objekt des Prototyps geklont
und kann unabhängig vom eigentlichen Objekt verwendet wer-
den.
– Singleton Pattern
Das Singleton Pattern wird mithilfe einer Klasse realisiert. Von
dieser Klasse kann nur ein Objekt instanziiert werden. Greifen
Sie anschließend auf das Entwurfsmuster zu, erhalten Sie
immer das ursprünglich instanziierte Objekt. Da stets mit Refe-
renzen auf diese einmalige Instanz gearbeitet wird, sind alle
64
Erzeugungsmuster 3
Änderungen an dem Objekt für alle Aufrufer gültig. Dieses Pat-
tern wird daher für den globalen Zugriff auf Instanzen verwen-
det.
In den folgenden Abschnitten erläutern wir die einzelnen Erzeu- Aufbau dieses
gungsmuster näher. Um Ihnen einen einfachen Überblick über die Kapitels
Entwurfsmuster zu geben und die Vergleichbarkeit zu gewährleis-
ten, sind die Abschnitte dabei jeweils nach der folgenden Struktur
gegliedert:
1. Problem
Zu jedem Entwurfsmuster beschreiben wir zunächst die Situation,
in der es angewendet werden kann.
2. Ansatz und Lösung
Im zweiten Schritt beschreiben wir den Lösungsansatz des jewei-
ligen Entwurfsmusters. Wir gehen anhand eines abstrakten Bei-
spiels darauf ein, wie das Entwurfsmuster und dessen Komponen-
ten aufgebaut sind und wie diese in Beziehung zu anderen Klassen
stehen. Ziel dieser Beschreibungen ist es, die Muster in der Praxis
anwenden zu können.
3. Einsatzbeispiele
Im nächsten Schritt führen wir mögliche Einsatzgebiete für die
einzelnen Entwurfsmuster an.
4. Umsetzung in ABAP
In den Abschnitten »Umsetzung in ABAP« zeigen wir Ihnen, wie
die Entwurfsmuster in ABAP realisiert werden können. Wir erläu-
tern dabei jeweils, wie das Entwurfsmuster aufgebaut wird und
welche Funktionen die einzelnen Methoden haben. Die Imple-
mentierung der einzelnen Entwurfsmuster erfolgt jeweils in
ABAP-Klassen, die wiederum verschiedene Unterklassen besitzen.
Aus Gründen der Übersichtlichkeit erstellen wir in unseren Bei-
spielen alle Klassen über die Transaktion SE24, den Class Builder.
5. Evaluation
Abschließend stellen wir jeweils die Vor- und Nachteile des
besprochenen Entwurfsansatzes einander gegenüber. Dadurch
möchten wir Ihnen die Entscheidung erleichtern, welches Ent-
wurfsmuster Sie am besten in Ihren Anwendungen und für Ihren
konkreten Zweck verwenden können. Viele Entwurfsmuster wei-
sen problematische Seiteneffekte auf, die aber durch eine Kombi-
nation mehrerer Entwurfsmuster minimiert werden können.
65
3 Erzeugungsmuster Builder Pattern 3.1

3.1 Builder Pattern

Client
Das Builder Pattern wird im Deutschen auch als Erbauermuster
bezeichnet und gehört zu den GoF-Mustern, also jenen Entwurfs-
mustern, die ursprünglich von der Gang of Four beschrieben wurden
(siehe auch Abschnitt 1.1, »Was sind Entwurfsmuster?«). Das Builder
Pattern trennt den Erzeugungsprozess eines komplexen Objekts von
der eigentlichen Verwendung dieses Objekts mithilfe von Klassen-
methoden. Dadurch ist es möglich, den Erzeugungsprozess, der in
Direktor Erbauer
diesem Zusammenhang auch oft Konstruktionsprozess genannt wird,
unabhängig von der Repräsentation anzuwenden. + konstruiere() + baue_teile()

3.1.1 Problem
Beispiel: Das Builder Pattern wird verwendet, um den Erzeugungsprozess
verschiedene komplexer Objekte von der Repräsentation dieser Objekte zu ent-
Exportwege
koppeln. Wir verdeutlichen dies anhand eines Beispiels. Sie können Produkt konkreter Erbauer
dieses Entwurfsmuster z. B. für eine Anwendung verwenden, die
+ baue_teile()
Daten aus einer Datenbanktabelle liest, diese Daten überarbeitet und
+ erhalte_ergebnis()
dann wieder in die Datenbank zurückschreibt. Möchten Sie dieser
Anwendung eine Exportschnittstelle hinzufügen, die Exportmöglich-
Abbildung 3.1 Builder Pattern – Aufbau im UML-Klassendiagramm
keiten in andere Anwendungen anbietet, können Sie unterschiedli-
che Builder definieren, die vom Anwender über die Anwendungs-
Klasse und ihre Rolle Beschreibung
oberfläche ausgewählt werden können, und sie jeweils in anderen
Datenformaten speichern. Ein solcher Builder erzeugt die Objekte, Erbauer Die Erbauerklasse ist eine abstrakte Klassen-
schnittstelle, die für die Erzeugung der komple-
die dann die Daten als CSV-Datei exportieren, ein weiterer Builder
xen Objekte und auch für die Erzeugung der Bau-
die Objekte, die Daten als XML-Dateien exportieren, und ein letzter teile zuständig ist.
Builder könnte die Daten über SAP Smart Forms als PDF aufbereiten
konkreter Erbauer Die Klasse des konkreten Erbauers kümmert sich
und exportieren. Auf diese Weise wird die eigentliche Verarbeitung darum, dass die einzelnen Bauteile während der
der Daten vom Exportprozess getrennt. Implementierung des Produkts erzeugt werden.
Die Erbauerklasse bzw. -schnittstelle gibt dem
konkreten Erbauer den Rahmen sowie die Defini-
3.1.2 Ansatz und Lösung tion vor, wie die Klasse des konkreten Erbauers
Mithilfe eines UML-Diagramms zeigen wir Ihnen zunächst, wie das durch die Repräsentationsschicht implementiert
werden kann. Über die Erbauerschnittstelle kann
Builder Pattern aufgebaut ist. In Abbildung 3.1 sehen Sie fünf ABAP-
das Objekt an das Produkt weitergegeben wer-
Klassen, die zusammen das Builder Pattern bilden.
den.
Bedeutung der Diese Klassen nehmen jeweils eine bestimmte Rolle im Entwurfs-
einzelnen Klassen Tabelle 3.1 Builder Entwurfsmuster – beteiligte Klassen
muster ein, die wir in Tabelle 3.1 genauer erläutern.

66 67
3 Erzeugungsmuster Builder Pattern 3.1

Klasse und ihre Rolle Beschreibung

Direktor Der Direktor erzeugt die komplexen Objekte konkreter
Client Direktor
Erbauer
mithilfe der Erbauerschnittstelle. Hier können
unterschiedliche Varianten hinterlegt werden,
die definieren, welche Arten von Produkten
neuer konkreter_erbauer()
erzeugt werden können und wie diese zusam-
mengebaut werden müssen. Beispiele sind ein
Auslagerungsauftrag für das Lager, ein Verschrot- neuer direktor(erbauer:ein_erbauer)

tungsauftrag oder ein Auftrag für die Ausbu-

chung von Material als Varianten des Objekts konstruiere()
Auftrag.
Produkt Als Produkt wird das zu konstruierende kom- erzeuge_bauteil_a()
plexe Objekt bezeichnet. Dieses Produkt basiert
auf Klassen, die zur Beschreibung der einzelnen erzeuge_bauteil_b()
Bauteile und Produkte erforderlich sind. Ein kon-
kretes Beispiel wäre ein Auftrag z. B. für die Ver- erzeuge_bauteil_c()
sendung o. Ä.
Client Der Client ist der Endanwender oder eine System- erhalte_ergebnis(erbautes:erbautes)
aktion, die z. B. über die Oberfläche einer Web-
Dynpro-Anwendung eine Aktion auslöst, z. B.
durch den Klick auf einen Button. Der Client
definiert so die Rahmenbedingungen für die Pro- Abbildung 3.2 Builder Pattern – UML-Sequenzdiagramm
dukterzeugung und gibt diese an den Direktor
weiter.
3.1.3 Einsatzbeispiel
Tabelle 3.1 Builder Entwurfsmuster – beteiligte Klassen (Forts.)
Um Ihnen die Einsatzgebiete des Builder Patterns zu verdeutlichen, Export aus
erläutern wir seine Verwendung exemplarisch anhand eines Daten- Web-Dynpro-
Sequenzdiagramm Das Sequenzdiagramm des Builder Patterns in Abbildung 3.2 können Anwendung
exports aus einer Anwendung in Web Dynpro ABAP. Dabei hat der
Sie wie folgt lesen: Der Client erzeugt zu Beginn ein Objekt vom Typ
Anwender verschiedene Möglichkeiten, einen Auftrag, den er aufge-
der Klasse für den konkreten Erbauer. Anschließend erzeugt der
rufen hat, zu exportieren. Der Auftrag kann nicht direkt als PDF
Client ein Objekt vom Typ Direktor. Nun ist die Grundlage für das
exportiert werden, sondern muss vor dem Export bearbeitet wer-
Builder Pattern geschaffen, und der Client kann eine der zentralen
den, um sicherzustellen, dass z. B. die Druckausgabe fehlerfrei funk-
Methoden aus dem Direktor-Objekt aufrufen. Dabei werden die
tioniert und alle Zeichen auf dem Formular korrekt und lückenlos
Methoden der Erbauerschnittstelle aufgerufen, die wiederum unter-
dargestellt werden.
schiedliche Bauteile für das Produkt über den konkreten Erbauer
erzeugen lassen. Dies kann ein Bauteil sein, es können aber auch Abbildung 3.3 veranschaulicht dieses Einsatzbeispiel anhand eines Klassendiagramm

mehrere Bauteile in Kombination sein. Als Ergebnis erhält der Client
das konstruierte standardisierte Objekt vom konkreten Erbauer
zurück.
UML-Diagramms. Die Klasse, die den Direktor repräsentiert, wird in
diesem Fall von der Web-Dynpro-Oberfläche über eine Aktion auf-
gerufen und stößt dadurch die Erzeugung des PDF-Exports (Objekt
der konkreten Erbauerklasse) an. Auf dieser Web-Dynpro-Oberflä-
che gibt es in unserem Beispiel einen Button, der die Methode
BUTTON_AUFTRAG_EXPORT_TO_PDF() auslöst. Klickt der Anwender auf
diesen Button, werden ihm unterschiedliche Exportmöglichkeiten

68 69
3 Erzeugungsmuster Builder Pattern 3.1

zur Auswahl gestellt. Die konkrete Klasse ERBAUER_EXPORT_1 enthält
alle Methoden, die zur Verfügung stehen, um das Auftragsdokument
zu überarbeiten und mit weiteren Informationen anzureichern. In
der Methode UEBERPRUEFE_EINGABEN() wird z. B. geprüft, ob diese
Daten korrekt sind. An dieser Stelle kann geprüft werden, ob der
Kunde, für den der Auftrag angelegt wurde, bereits im System vor-
handen ist, ob für ihn eine Bonitätsprüfung vorliegt und vieles mehr.
«Builder»
Direktor erbauer_export_1
auftrag:dokument
+ erzeuge_pdf_dokument()
+ button_auftrag_export_to_pdf() :void + erzeuge_sap_report()
+ erzeuger_auftrag_verkauf(dokument) + erzeuge_ausdruck_bei_drucker()
+ ueberpruefe_eingaben()
+ ueberarbeite_texteingaben()
+ interpretiere_eingaben()
Aufruf 1:
button_erzeuge_auftrag(){
erzeuger_1.ueberpruefe_eingaben();
erzeuger_1.ueberarbeite_texteingaben();
erzeuger_1.interpretiere_eingaben();
erzeuger_1.erzeuge_pdf_dokument(); + pruefe_auf_ungueltige_zeichen()
} + pruefe_auf_pflichteingaben()
+ pruefe_auf_plausibilitaet()
Aufruf 2: + gleiche_eingaben_mit_merkmalswerte_ab()
button_erzeuge_auftrag(){
erzeuger_1.ueberpruefe_eingaben();
erzeuger_1.ueberarbeite_texteingaben(); Interpretiere
erzeuger_1.interpretiere_eingaben();
erzeuger_1.erzeuge_sap_report(); + pruefe_bonitaet()
erzeuger_1.erzeuge_ausdruck_bei_drucker(); + pruefe_fruehestmoeglicher_liefertermin()
} + pruefe_lagerbestand()
Abbildung 3.3 Builder Pattern – UML-Klassendiagramm für Beispielanwendung
Unterklassen Die Methoden, die von der Erbauerklasse angesprochen werden,
beinhalten einen standardisierten Aufruf der Unterklassenmethoden
INTERPRETIERE(), TEXTEINGABEN() und UEBERPRUEFE_EINGABEN().
Die Unterklassen sind so realisiert worden, dass jede dieser Klassen
andere Methoden aufrufen kann. Sie sind als ein Pool von Funktio-
nen zu verstehen, die Sie verwenden können. Dazu werden jeweils
nur die Informationen benötigt, die die Methoden selbst anfordern.
Die Erzeugungsmethoden der Builder-Klasse rufen mit den Unter-
klassen mehrere dieser Funktionen auf, um die Texte und Eingaben
im Auftragsformular zu überprüfen. Sie können an dieser Stelle alle
komplexen Methoden programmieren, die für Ihren Einsatzzweck
notwendig sind.
Aufruf mehrerer Funktionen
Mithilfe des Builder Patterns können Sie z. B. einen Methodenaufruf
implementieren, der die erforderlichen Buchungen im Buchungssystem
Überprüfe Eingaben
+ ist_backend_system_korrekt()
+ ist_wiw_korrekt()
+ ist_adresse_korrekt()
+ pruefe_bestellpostionen()
+ pruefe_pflichtfelder()
«Produkt»
Texteingaben
durchführt, den Kunden darüber benachrichtigt, dass sein Auftrag in
Bearbeitung ist, und zusätzlich noch einen weiteren Workflow startet.
Dies kann sehr einfach über den Methodenpool der Subklassen realisiert
werden. In dem Subsystem werden dabei z. B. zentrale Klassen des SAP-
Systems oder Eigenentwicklungen aufgerufen, die die gewünschten Akti-
onen im System durchführen.
3.1.4 Umsetzung in ABAP
In diesem Abschnitt zeigen wir Ihnen, wie Sie das Builder Pattern in Report
ABAP umsetzen können. Wir greifen dazu auf das Beispiel aus Abbil-
dung 3.2 zurück. Zur Implementierung des Builder Patterns erstellen
wir einen ABAP-Report in Transaktion SE38. In diesem Report wird
das Pattern umgesetzt und kann hier später auch ausgeführt werden.
Wird der Report später in eine Anwendung integriert, findet dies
meistens in einer Verarbeitungsklasse statt, die wiederum ihre eige-
nen Klassen besitzt. Wir verzichten in diesem Kapitel darauf, alle
diese Klassen in Transaktion SE24 anzulegen, um das Beispiel für Sie
übersichtlicher zu gestalten.
Durch das Erzeugen des ABAP-Reports öffnet sich der ABAP Editor
mit der folgenden Codezeile:
REPORT zdp_ar_erz_builder.
Listing 3.1 zeigt die Definition der Klasse, in der das Produkt defi- Produktklasse
niert wird. Diese Produktklasse beinhaltet zwei Methoden und ein
internes Attribut. Das interne Attribut hat den Datentyp STRING und
enthält den Namen des Bauteils. Es können noch weitere Informati-
onen und Objekte in dieser Klasse abgelegt werden. Die Methoden
fügen die neuen Bauteile in das Attribut I_BAUTEILE der Klasse ZDP_
CL_BUILD_PRODUKT hinzu. Über die Methode ANZEIGEN() können die
Bauteile ausgegeben werden, die im Produkt erzeugt wurden. Die
Methode HINZUFUEGEN() fügt der Bauteilliste neue Bauteile hinzu.
CLASS zdp_cl_build_produkt DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
DATA bauteile TYPE TABLE OF string.
METHODS hinzufuegen
IMPORTING
!i_bauteile TYPE string.

70 71
3 Erzeugungsmuster Builder Pattern 3.1

METHODS anzeigen. PROTECTED SECTION.

PROTECTED SECTION. PRIVATE SECTION.
PRIVATE SECTION. ENDCLASS.
ENDCLASS.
Listing 3.3 Definition der Erbauerklasse innerhalb des Builder Patterns
Listing 3.1 Builder Pattern – Definition der Produktklasse
Als erster konkreter Erbauer wird in Listing 3.4 die Klasse des kon- Erster konkreter
Nach der Definition der Klasse muss diese noch implementiert wer- kreten Erbauers ZDP_CL_BUILD_KONERB1 erstellt. Durch die abstrakte Erbauer
den. Die Implementierung sehen Sie in Listing 3.2. Klasse ZDP_CL_BUILD_ERBAUER wurde definiert, welche Methoden in
CLASS zdp_cl_build_produkt IMPLEMENTATION. den einzelnen konkreten Erbauern implementiert werden müssen.
METHOD hinzufuegen.
CLASS zdp_cl_build_konerb1 DEFINITION
APPEND i_bauteile TO bauteile.
PUBLIC
ENDMETHOD. INHERITING FROM zdp_cl_build_erbauer
METHOD anzeigen. FINAL
DATA: ls_ausgabezeile TYPE string. CREATE PUBLIC.
WRITE:/ 'Produkt -- Welche Bauteile sind vorhanden? --'.
LOOP AT bauteile INTO ls_ausgabezeile. PUBLIC SECTION.
WRITE:/ 'Objekt: ' && ls_ausgabezeile. METHODS constructor.
ENDLOOP. METHODS erzeuge_bauteil_a
ENDMETHOD. REDEFINITION.
ENDCLASS. METHODS erzeuge_bauteil_b
Listing 3.2 Builder Pattern – Implementierung der Produktklasse REDEFINITION.
METHODS erhalte_ergebnis
REDEFINITION.
Erbauerklasse Im nächsten Abschnitt, den Sie in Listing 3.3 sehen, definieren wir PROTECTED SECTION.
die Klasse ZDP_CL_BUILD_ERBAUER. Die abstrakte Klasse ZDP_CL_ PRIVATE SECTION.
BUILD_ERBAUER definiert eine Hülle für die eigentlichen Erbauerklas- DATA produkt TYPE REF TO zdp_cl_build_produkt.
sen ZDP_CL_BUILD_KONERB1 und ZDP_CL_BUILD_KONERB2. In der
CLASS zdp_cl_build_konerb1 IMPLEMENTATION.
Erbauerklasse wird definiert, welche Methoden von den konkreten
METHOD constructor.
Erbauerklassen implementiert werden müssen. In unserem Beispiel CALL METHOD super->constructor.
sind dies die Methoden ERZEUGE_BAUTEIL_A() und ERZEUGE_BAU- CREATE OBJECT me->produkt.
TEIL_B(). Anschließend wird das Objekt PRODUKT über den Rückga- ENDMETHOD.
beparameter R_PRODUKT der Methode ERHALTE_ERGEBNIS() an den
METHOD erzeuge_bauteil_a.
Aufrufer/Direktor bzw. Client zurückgegeben. produkt->hinzufuegen('Bauteil-A').
CLASS zdp_cl_build_erbauer DEFINITION ENDMETHOD.
PUBLIC ABSTRACT METHOD erzeuge_bauteil_b.
produkt->hinzufuegen('Bauteil-B').
CREATE PUBLIC.
ENDMETHOD.
PUBLIC SECTION.
METHOD erhalte_ergebnis.
produkt = me->produkt.
METHODS erzeuge_bauteil_a.
r_produkt = me->produkt.
METHODS erzeuge_bauteil_b.
ENDMETHOD.
METHODS erhalte_ergebnis
ENDCLASS.
RETURNING
VALUE(r_produkt) TYPE REF TO zdp_cl_build_produkt. Listing 3.4 Builder Pattern – Definition des konkreten Erbauers

72 73
3 Erzeugungsmuster Builder Pattern 3.1

Zweiter konkreter In Listing 3.5 wird die Klasse des zweiten konkreten Erbauers ZDP_ Als Nächstes implementieren Sie den Direktor wie in Listing 3.6. Der Direktor
Erbauer CL_BUILD_KONERB2 implementiert. Es können unterschiedliche Direktor ist dafür zuständig, die Erzeugung der unterschiedlichen
Erbauer erstellt werden, die dem Produkt unterschiedliche Bauteile Bauteile des Produkts anzustoßen und diese in dem Produkt abzu-
hinzufügen können. In einer Unternehmensanwendung kann das speichern. Der Direktor wird vom Client über die Methode KONSTRU-
Produkt z. B. ein Auftrag sein. Der erste konkrete Erbauer erzeugt IERE() aufgerufen. Dieser Aufruf führt dazu, dass die unterschiedli-
dann z. B. Produktionsaufträge, ein zweiter konkreter Erbauer z. B. chen Bauteile für das Produkt erzeugt werden.
Lieferaufträge.
CLASS zdp_cl_build_direktor DEFINITION
CLASS zdp_cl_build_konerb2 DEFINITION PUBLIC FINAL
PUBLIC CREATE PUBLIC.
INHERITING FROM zdp_cl_build_erbauer PUBLIC SECTION.
FINAL CREATE PUBLIC. METHODS konstruiere
PUBLIC SECTION. IMPORTING
METHODS constructor. !i_erbauer TYPE REF TO zdp_cl_build_erbauer.
METHODS erzeuge_bauteil_a PROTECTED SECTION.
REDEFINITION. PRIVATE SECTION.
METHODS erzeuge_bauteil_b ENDCLASS.
REDEFINITION.
METHODS erhalte_ergebnis CLASS zdp_cl_build_direktor IMPLEMENTATION.
REDEFINITION. METHOD konstruiere.
PROTECTED SECTION. i_erbauer->erzeuge_bauteil_a( ).
PRIVATE SECTION. i_erbauer->erzeuge_bauteil_b( ).
DATA produkt TYPE REF TO zdp_cl_build_produkt. ENDMETHOD.
ENDCLASS. ENDCLASS.
Listing 3.6 Builder Pattern – Definition der Direktorklasse
CLASS zdp_cl_build_konerb2 IMPLEMENTATION.
METHOD constructor.
Die Klasse ZDP_CL_BUILD_APPLIKATION, deren Implementierung Sie Client
CALL METHOD super->constructor.
CREATE OBJECT me->produkt. in Listing 3.7 sehen, ist die Anwendungsklasse, die den Client reprä-
ENDMETHOD. sentiert. In dieser Klasse treffen alle Komponenten zusammen, die
für das Builder Pattern benötigt werden. In der einzigen Methode
METHOD erzeuge_bauteil_a. START() werden zunächst alle Objekte der unterschiedlichen Klassen
produkt->hinzufuegen('Bauteil-X').
erzeugt, die benötigt werden, um den Direktor aufzurufen. Der
ENDMETHOD.
Direktor lenkt dann automatisch alle Aktionen, um das Produkt mit
METHOD erzeuge_bauteil_b. seinen Bauteilen zu erzeugen.
produkt->hinzufuegen('Bauteil-Y').
CLASS zdp_cl_build_applikation DEFINITION
ENDMETHOD.
PUBLIC FINAL
CREATE PUBLIC.
METHOD erhalte_ergebnis.
PUBLIC SECTION.
produkt = me->produkt.
DATA lo_erbauer TYPE REF TO zdp_cl_build_erbauer.
r_produkt = produkt.
METHODS start.
ENDMETHOD.
PROTECTED SECTION.
ENDCLASS.
PRIVATE SECTION.
Listing 3.5 Builder Pattern – Definition des zweiten konkreten Erbauers ENDCLASS.

74 75
3 Erzeugungsmuster
CLASS zdp_cl_build_applikation IMPLEMENTATION.
METHOD start.
DATA: lo_direktor TYPE REF TO zdp_cl_build_direktor.
DATA: lo_b1 TYPE REF TO zdp_cl_build_konerb1.
DATA: lo_b2 TYPE REF TO zdp_cl_build_konerb2.
DATA: lo_p1 TYPE REF TO zdp_cl_build_produkt.
DATA: lo_p2 TYPE REF TO zdp_cl_build_produkt.
CREATE OBJECT lo_direktor.
CREATE OBJECT lo_b1.
CALL METHOD lo_direktor->konstruiere( lo_b1 ).
lo_p1 = lo_b1->erhalte_ergebnis( ).
lo_p1->anzeigen( ).
CREATE OBJECT lo_b2.
CALL METHOD lo_direktor->konstruiere( lo_b2 ).
lo_p2 = lo_b2->erhalte_ergebnis( ).
lo_p2->anzeigen( ).
ENDMETHOD.
ENDCLASS.
Listing 3.7 Builder Pattern – Definition und Implementierung der Applikationsklasse
Integration in Um das Builder Pattern in einer Anwendung verwenden zu können,
Report muss jetzt nur noch die Applikationsklasse aufgerufen werden. Der
Quellcode dieser Klasse kann auch direkt in eine Anwendung inte-
griert werden. In unserem Beispiel integrieren wir den Quellcode in
einen ABAP-Report mit der folgenden Codezeile:
REPORT zdp_ar_erz_builder.
DATA lo_app TYPE REF TO zdp_cl_build_applikation.
CREATE OBJECT lo_app.
lo_app->start( ).
Listing 3.8 Builder Pattern – Aufruf im ABAP-Report
Report ausführen Das Ergebnis dieser Implementierung erhalten Sie durch die Ausfüh-
rung des ABAP-Reports ZDP_AR_ERZ_BUILDER über Transaktion SE38.
Dabei wird die in Abbildung 3.4 dargestellte Ausgabe angezeigt.
Anhand der Ausgabe in der Ausführungskonsole erkennen Sie, wie
die einzelnen Objekte aufgebaut sind, die durch das Builder Pattern
erzeugt wurden. Sie sehen, dass das Produkt 1 erzeugt wurde, in
dem die Bauteile A und B enthalten sind. Diese Objekte wurden
76
Builder Pattern 3.1
durch den konkreten Erbauer 1 erzeugt. Hingegen wurden bei Pro-
dukt 2 die Bauteile X und Y durch den konkreten Erbauer 2 erzeugt.
Abbildung 3.4 Builder Pattern – Reportausgabe
3.1.5 Evaluation
Ein entscheidender Vorteil des Builder Patterns ist, dass bei der Vorteile
Implementierung die Objekte der Repräsentationsschicht komplett
von den Konstruktionsobjekten bzw. der Konstruktionsschicht iso-
liert sind. Dies wird durch die Objektkapselungen erreicht. Das
bedeutet, dass die Anwendung sehr robust und weniger angreifbar
durch Injections (Angriffe z. B. durch Hacking) sowie weniger fehler-
anfällig durch die Kapselungen ist.
Ein weiterer Vorteil ist, dass die Erbauerklasse als Repräsentant nach
außen dient, d .h. für andere Klassen der Anwendung oder für den
Client über die Benutzeroberfläche aufrufbar ist. In der Repräsentati-
onsschicht werden die internen Klassen, d. h. die konkreten
Erbauer, vor dem Direktor versteckt. Die einzelnen Klassen sind
dabei voneinander isoliert, obwohl sie in einer Anwendung zusam-
menarbeiten.
Ein weiterer wichtiger Grund, dieses Entwurfsmuster zu verwenden,
ist, dass der gesamte Konstruktionsprozess über eine zentrale Stelle,
den Direktor, gesteuert wird. Dieser Konstruktionsprozess kann
über die verschiedenen konkreten Erbauerklassen in mehrere Pha-
sen untergliedert werden, was z. B. beim Factory Pattern (siehe
Abschnitt 3.2) nicht der Fall ist. Dazu sind seitens des Clients keine
weiteren Aktivitäten notwendig.
Auch bei einer späteren Weiterentwicklung der Anwendung hat die
Verwendung des Builder Patterns Vorteile. Da die Methoden in ein-
zelnen Klassen gekapselt vorliegen, können sehr einfach weitere
77
3 Erzeugungsmuster
Klassen hinzugefügt werden, um neue Produkte zu erzeugen. Möch-
ten Sie eine Anwendung entwickeln, die auf neue Anforderungen
durch neue Objekte sehr schnell und einfach reagieren kann, emp-
fehlen wir Ihnen die Verwendung dieses Entwurfsmusters.
Nachteile Um das Builder Pattern zu implementieren, sind allerdings umfas-
sende und vollständige Kenntnisse des Konstruktionsprozesses aller
Objekte der Anwendung erforderlich. Nur so können die Objekte in
der Laufzeitumgebung richtig eingesetzt werden. Dies bedeutet, dass
bei komplexen Anwendungen alle Objekte vor der Umsetzung erst
einmal dokumentiert bzw. evaluiert werden müssen. Dies ist umso
mehr erforderlich, als die Objekte später bei der Implementierung
nur noch isoliert voneinander betrachtet werden.
Ein weiterer erheblicher Nachteil ist, dass die Klassen beim Builder
Pattern sehr stark miteinander verzahnt sind. Diese Kopplung
erlaubt es nicht, die Klassen in anderen Klassen einfach wiederzuver-
wenden.
3.2 Factory Pattern
Das Factory Pattern wird im Deutschen auch als Fabrik-Entwurfs-
muster bezeichnet und gehört ebenso wie das Builder Pattern zu den
GoF-Entwurfsmustern. Das Factory Pattern wird eingesetzt, um die
Konstruktion von Objekten von ihren Repräsentationen zu trennen.
Im Unterschied zum Builder Pattern kann das Factory Pattern aber
nicht so einfach nach Belieben ausgebaut werden. Ein mit dem Fac-
tory Pattern verwandtes Pattern ist das Singleton Pattern, das wir in
Abschnitt 3.3 erläutern.
Merkmale des Ein mithilfe des Factory Patterns implementierter Konstruktionspro-
Konstruktions- zess kann jederzeit wiederverwendet werden. Beim Factory Pattern
prozesses
werden privat deklarierte Konstrukte, die Methoden und Konstruk-
toren, dazu verwendet, eine direkte Instanziierung von anderen
Klassen zu verhindern. Stattdessen erfolgt die Objekterzeugung mit-
hilfe einer statischen Methode. Das Objekt wird über diese statische
Methode zurückgegeben.
Factory-Typen Es gibt die folgenden drei Möglichkeiten, ein Factory Pattern zu
implementieren:
78
Factory Pattern 3.2
왘 Factory Pattern auf Basis von Methoden
Factory-Methoden sind statische Methoden, die zur Erzeugung
von Objekten eines Klassentyps verwendet werden. Das Singleton
Pattern nutzt die Factory-Methode. Dabei liest das Pattern das zu
erstellende Objekt durch die statischen Methoden aus oder lässt
dieses Objekt instanziieren.
왘 Factory Pattern auf Basis von Klassen
Eine Factory-Klasse basiert auf dem Factory-Methoden-Konzept
und erweitert dieses Konzept durch verschiedene Klassen. In Fac-
tory-Klassen werden nicht nur die zur Entwurfsmusterimplemen-
tierung gehörenden Klassen instanziiert, sondern auch vollstän-
dige und komplexe andere Objekte. So wird ein höherer
Abstraktionsgrad erzielt, der es viel leichter erlaubt, eine Factory-
Klasse durch andere Klassen auszutauschen, die ebenfalls dem
Konzept der Factory-Klasse entsprechen.
왘 Factory Pattern auf Basis abstrakter Klassen und Interfaces
Die Implementierung mit einer abstrakten Factory-Klasse ist eine
sehr aufwendige Implementierungsvariante des Entwurfsmusters.
Oft trägt diese Umsetzungsvariante auch den Spitznamen Toolkit.
Die abstrakte Factory-Klasse hat zwei wichtige Merkmale, die
gleichzeitig ihre Vorteile ausmachen:
– Während des Erzeugungsprozesses wird nicht nur ein konkre-
tes Element (d. h. ein Objekttyp) erzeugt, sondern es können
viele und unterschiedliche Elemente erzeugt werden.
– Darüber hinaus ist die abstrakte Factory-Klasse sehr flexibel
gebaut, was das Hinzufügen und Austauschen von Objekten
anhand zusätzlicher Factories vereinfacht.
3.2.1 Problem
Ein Objekt besitzt verschiedene Parameter, die bei der Erzeugung Gruppierung der zu
dieses Objekts unterschiedlich angelegt werden müssen. Es können erzeugenden
Parameter
z. B. unterschiedliche Aufträge erzeugt werden, die alle anhand eines
Parameters definiert werden. Dazu können Standardinformationen,
wie z. B. die Auftragsnummer, das Tagesdatum etc. bereits im Rah-
men der Objekterzeugung festgelegt werden.
79
3 Erzeugungsmuster Factory Pattern 3.2

Das Factory Pattern stellt dazu eine Schnittstelle bereit, die die Diese Factory-Klassen erzeugen die Produkte für den Client, z. B.
Objekte entsprechend erzeugt. Die erzeugten Objekte können mitei- einen Auftrag. Wie dies im Detail abläuft, erläutern wir in diesem
nander verwandt oder auf andere Weise voneinander abhängig sein. Abschnitt.

Abbildung 3.6 zeigt ein UML-Klassendiagramm zur technischen Umsetzung in

Umsetzung dieses Modells. Sie erkennen fünf ABAP-Klassen, über Klassen
3.2.2 Ansatz und Lösung
Aufbau Eine Skizze, wie das Factory Pattern umgesetzt werden kann, finden die der Konstruktionsprozess in der Factory-Klasse abgebildet wird:
Sie in Abbildung 3.5. Hier sollen Aufträge in verschiedenen SAP-
ERP-Komponenten erzeugt werden. Auf der linken Seite ist der
Client
Anwender eingezeichnet, der auch als Client bezeichnet wird. Dieser
kann entweder eine abstrakte Factory oder eine konkrete Factory-
Klasse anstoßen. Eine abstrakte Factory wird verwendet, wenn spä-
ter unterschiedliche konkrete Factory-Klassen implementiert werden
sollen. Die einfachste Variante ist es, nur eine Factory-Klasse zu
implementieren. Dabei greift der Anwender direkt auf die konkrete abstrakte_factory abstrakter_auftrag
Factory-Klasse zu. Die konkrete Factory-Klasse bzw. die -Klassen «erzeuge»
+erzeuge_auftrag() :abstrakter_auftrag
erzeugen einzelne Objekte und geben diese als Objektreferenz
zurück. In Abbildung 3.5 ist dieses Objekt der konkrete Auftrag, der
auf einer Klasse basiert.

abstrakte Factory konkrete_factory auftrag

konkreter
Auftrag +erzeuge_auftrag() :abstrakter_auftrag
Anwender

Abbildung 3.6 Factory Pattern – UML-Klassendiagramm

konkrete Factory
für FI

abstrakter konkreter 왘 Abstrakte Factory-Klasse

Auftrag Auftrag Die Klasse abstrakte_factory hat die Aufgabe, Objekte von drit-
ten Klassen zu erzeugen und diese dem Anwender bereitzustellen.
Dies können abstrakte oder implementierte Klassen sein. Die
konkrete Factory
abstrakte_factory wird im Klassendiagramm als Superklasse dar-
für MM
konkreter
Auftrag gestellt.
왘 Konkrete Factory-Klasse
Neue Factory-Klassen erben von der abstrakten Superklasse und
konkrete Factory
für SD
heißen konkrete_factory. Die konkreten Factory-Klassen enthal-
ten die Methoden zur Objekterzeugung, in unserem Beispiel der
Klasse auftrag. Abhängig von der Komplexität des zu erzeugen-
Abbildung 3.5 Factory Pattern – Aufbau

80 81
 3 Erzeugungsmuster
den Objekts können dazu unterschiedlich viele Factory-Klassen
verwendet werden.
Die konkreten Factory-Klassen übergeben die Objekte mithilfe
eines Rückgabewertes an die Klasse client, also der Anwender,
zurück. Die abstrakte Factory-Klasse definiert den Rahmen, welche
Methoden in den konkreten Factory-Klassen zur Verfügung stehen.
Durch den Aufruf eines Objekts dieser Factory-Klasse wird dieses
Objekt durch die Methode erzeuge_auftrag() erzeugt. Der An-
wender erhält von dem abstrakten Factory-Klassen-Objekt ein
Objekt zurück, nämlich seinen konkreten Auftrag. In unserem
Beispiel können unterschiedliche Aufträge auf Basis verschiedener
Klassen erzeugt werden, die eine gemeinsame Superklasse abs-
trakter_auftrag haben. Um die konkreten Klassen ausprägen zu
können, müssen diese zunächst klassifiziert werden. Diese Klassi-
fizierung erfolgt ebenfalls über eine Factory-Klasse, die dem An-
wender in der Klasse client zur Verfügung gestellt wird.
왘 Client
Der Client selbst hat mit der eigentlichen Erzeugung der konkre-
ten Objekte nichts zu tun. Seine einzige Aufgabe ist es, die Factory-
Klasse auszuwählen, die das Objekt erzeugen soll. Für den Ausla-
gerungsauftrag in der SAP-Komponente SD muss z. B. eine Klasse
erzeugt werden. Das Factory Pattern stellt alle erforderlichen
Funktionen für die Erzeugung der Objekte zur Verfügung.
Zusätzliche Der entscheidende Vorteil des abstrakten Factory Patterns ist die
Abstraktionsebene Nutzung der zusätzlichen Abstraktionsebene für die Objekterzeu-
gung. Der Client nutzt zur Laufzeit die durch die abstrakte Klasse
abstrakte_factory zur Verfügung gestellten Methoden. Diese
Klasse ist ein Platzhalter für eine konkrete Klasse zur Auftragserzeu-
gung, die von dieser Klasse erbt und dadurch alle Standardmethoden
von ihr übernimmt. Die Ausimplementierung der abstrakten Klasse
erfolgt in der Klasse konkrete_factory. Diese bleibt dem Client ver-
borgen, er kann sie jedoch für die Objekterzeugung nutzen.
Ablauf einer In Abbildung 3.7 haben wir den Ablauf einer nach dem Factory Pat-
Factory-Pattern- tern konzipierten Anwendung in einem Sequenzdiagramm skizziert.
Anwendung
Der Client ruft hier eine Methode auf. Diese Methode wird z. B. über
die Anwendungsoberfläche vom Anwender ausgelöst, z. B. durch
den Klick auf einen Button. Die Implementierung dieser Methode
ruft wiederum eine Methode der abstrakten Factory-Klasse auf.
82
Factory Pattern 3.2
Dabei werden weitere Methoden angestoßen, die dann sowohl das
Objekt des Auftrags als auch das der konkreten Factory-Klasse erzeu-
gen. Diese abstrakte Factory ruft die Methode factory_methode() in
der konkreten Factory-Klasse auf. Diese Methode erzeugt ein kon-
kretes Objekt, in diesem Fall einen Auftrag auf Basis der Informatio-
nen, die sie über die abstrakte bzw. die konkrete Factory-Klasse
erhalten hat. Dieses erzeugte Objekt wird über die Rückgabeparame-
ter der Methode zurück an die Client-Klasse gegeben. Zur Objekter-
zeugung spricht der Client die konkrete Factory-Klasse über die abs-
trakte Factory-Klasse an.
Client abstrakte_ konkrete_factory konkreter_auftrag
factory
eine_operation()
factory_methode()
erzeuge_konkreter_auftrag()
Abbildung 3.7 Factory Pattern – UML-Sequenzdiagramm
3.2.3 Einsatzbeispiel
Das Factory Pattern kann auch dann verwendet werden, wenn das zu
erzeugende Objekt der erzeugenden Klasse unbekannt sein soll. Erst
durch die Unterklassen wird definiert, welche Objekte erzeugt wer-
den sollen. Auf diese Weise können durch die Factory-Klassen ganz
unterschiedliche Objekte erzeugt werden. Der Aspekt der Erzeugung
wird in der Factory-Klasse zentralisiert und völlig von den zu erzeu-
genden Objekten getrennt.
In Abbildung 3.8 skizzieren wir als Beispiel eine Anwendung zur Beispiel:
Belegarten
Erzeugung verschiedener Belegarten im SAP-Finanzwesen FI (Einbu-
erzeugen
chungs-, Ausbuchungs- und Umbuchungsbelege). Dabei kann es sich
z. B. um Einbuchungsbelege für bestimmte Paletten in einem Lager
handeln. Mit der konkreten Factory-Klasse ZDP_CL_FI_VERARBEITUNG
lassen sich unterschiedliche Belegarten erzeugen. Die Belegobjekte
werden hier zentral erzeugt und zurückgegeben. Die konkrete Erzeu-
83
3 Erzeugungsmuster Factory Pattern 3.2

gung der unterschiedlichen Belegarten erfolgt dann in unterschiedli-
chen Factory-Methoden ERZEUGE_FI_AUSBUCHUNG(), ERZEUGE_FI_
EINBUCHUNG() und ERZEUGE_FI_UMBUCHUNG().
Anstelle der konkreten Factory-Klasse können Sie auch mit einer abs-
trakten Factory-Klasse arbeiten und erbende Factory-Klassen zwi-
schenschalten. So hätten Sie eine breitere Schnittstelle, die Ihnen
mehr Möglichkeiten bietet, unterschiedliche Belegarten zu erzeugen.
Sinnvoll ist diese Abstraktionsebene nur, wenn die Clusterung der
Belegerzeugung innerhalb eines Projekts möglich ist. Die Klasse ZDP_
CL_FI_VERARBEITUNG kann in der Implementierung sehr einfach
3.2.4 Umsetzung in ABAP
In diesem Abschnitt setzen wir das Factory Pattern in einer ABAP- Belegerzeugung
Anwendung um, die zwei verschiedene Belegarten erzeugt, und set- mit abstrakter
Factory
zen dabei in Erweiterung des Beispiels aus dem vorangegangenen
Abschnitt eine abstrakte Factory-Klasse ein. Die beiden Belegarten
Einbuchungs- und Ausbuchungsbeleg werden von zwei verschiede-
nen Factory-Klassen erzeugt. Diese beiden Objektklassen basieren
auf der abstrakten Superklasse ZDP_CL_FACT_BELEG. Die konkreten
Erbauerklassen basieren auf der abstrakten Factory-Superklasse ZDP_
CL_FACT_ERBAUER, die alle Informationen zentral für die konkreten

durch die Anwendung, also den Client, angesprochen werden. Beim Factory-Klassen bereitstellt. Die konkreten Erbauerklassen erben
Erzeugen der einzelnen FI-Belege werden diese Belege über das also von dieser Superklasse ZDP_CL_FACT_ERBAUER.
Attribut I_BELEGE durch die Methode HINZUFUEGEN() einer internen Für das Factory Pattern legen Sie zunächst über Transaktion SE38 Report zur
Tabelle hinzugefügt. Diese Methode HINZUFUEGEN() wird über eine einen ABAP-Report an. Klassendefinition
Client-Klasse aufgerufen, in unserem Beispiel bezeichnen wir sie als
REPORT zdp_ar_erz_factory.
ZDP_CL_CLIENT.
In Listing 3.9 wird die abstrakte Superklasse ZDP_CL_FACT_BELEG Definition
definiert. Superklasse
FI-Beleg
CLASS zdp_cl_fact_beleg DEFINITION
PUBLIC
ABSTRACT
CREATE PUBLIC.

PUBLIC SECTION.
PROTECTED SECTION.
FI-Einbuchungsbeleg FI-Ausbuchungsbeleg FI-Umbuchungsbeleg
PRIVATE SECTION.
(Rechnung)
ENDCLASS.
Listing 3.9 Factory Pattern – Definition der Beleg-Superklasse

FI-Verarbeitung
Im nächsten Schritt werden die konkreten Belegklassen ZDP_CL_FACT_ Definition der
- I_BELEGE :LISTE<BELEGE> konkreten
KONBELEIN für den Einbuchungsbeleg und ZDP_CL_FACT_KONBELAUS
Factory-Methoden: Belegklassen
+ ERZEUGE_FI_AUSBUCHUNG() :FI_BELEG
ERZEUGE_FI_AUSBUCHUNG( ) für den Ausbuchungsbeleg definiert (siehe Listing 3.10). Diese Beleg-
+ ERZEUGE_FI_EINBUCHUNGSBELEG() :FI_BELEG
ERZEUGE_FI_EINBUCHUNG( ) klassen erben von der in Listing 3.9 definierten Superklasse ZDP_CL_
+ ERZEUGE_FI_UMBUCHUNG() :FI_BELEG
ERZEUGE_FI_UMBUCHUNG( )
FACT_BELEG. Die Belegklassen selbst können Sie noch ausgestalten,
um die verschiedenen Belegausprägungen zu definieren.

CLASS zdp_cl_fact_konbelein DEFINITION

CLIENT_HINZUFUEGEN( ERZEUGE_FI_AUSBUCHUNG( DETAILS_ZUR_AUSBUCHUNG ))
PUBLIC
CLIENT_HINZUFUEGEN( ERZEUGE_FI_EINBUCHUNG( DETAILS_ZUR_EINBUCHUNG ))
INHERITING FROM zdp_cl_fact_beleg
CLIENT_HINZUFUEGEN( ERZEUGE_FI_UMBUCHUNG( DETAILS_ZU_DEN_KONTEN ))
FINAL
CREATE PUBLIC.
Abbildung 3.8 Factory Pattern – UML-Klassendiagramm einer Beispielanwendung

84 85
3 Erzeugungsmuster Factory Pattern 3.2

PUBLIC SECTION. In Listing 3.12 wird definiert, dass die konkrete Erbauerklasse ZDP_ Definition
PROTECTED SECTION. CL_FACT_KONERBEIN von der abstrakten Klasse ZDP_CL_FACT_ERBAUER der erbenden
PRIVATE SECTION. Factory-Klassen
erbt. Dies bedeutet, dass alle Methoden der vererbenden Klasse in
ENDCLASS.
der Klasse ZDP_CL_FACT_KONERBEIN zur Verfügung stehen. Damit die
CLASS zdp_cl_fact_konbelaus DEFINITION konkrete Erbauerklasse den Einbuchungsbeleg erzeugt, muss die
PUBLIC Methode ERZEUGE_BELEG() redefiniert werden. Dabei bleibt die
INHERITING FROM zdp_cl_fact_beleg Methode der Superklasse unverändert. Sie wird bei der Redefinition
FINAL
lediglich für die Objekte der Klasse ZDP_CL_FACT_KONERBEIN über-
CREATE PUBLIC.
schrieben. Bei der Klasse ZDP_CL_FACT_KONERBAUS funktioniert dieses
PUBLIC SECTION. Prinzip auf die gleiche Weise.
PROTECTED SECTION.
PRIVATE SECTION. CLASS zdp_cl_fact_konerbein DEFINITION
ENDCLASS. PUBLIC
INHERITING FROM zdp_cl_fact_erbauer
Listing 3.10 Factory Pattern – Definition der erbenden Belegklassen
FINAL
CREATE PUBLIC.
Definition der In Listing 3.11 wird die abstrakte Factory-Klasse definiert und imple-
abstrakten mentiert – also die Klasse, der innerhalb des Factory Patterns die PUBLIC SECTION.
Erbauer-Factory METHODS erzeuge_beleg
Rolle des Erbauers zukommt. Die Factory-Klasse ist für den Erzeu-
REDEFINITION.
gungsprozess der zwei Belegtypen zuständig. Von der abstrakten
PROTECTED SECTION.
Superklasse ZDP_CL_FACT_ERBAUER erben in unserem Beispiel zwei PRIVATE SECTION.
konkrete Factory-Klassen. Durch Realisierung der Factory-Klasse als ENDCLASS.
abstrakte Superklasse ist es möglich, die Anzahl der erbenden Fac-
tory-Klassen beliebig zu erhöhen. Diese Factory-Klassen verfügen CLASS zdp_cl_fact_konerbein IMPLEMENTATION.
METHOD erzeuge_beleg.
jeweils über die gleiche Methode ERZEUGE_BELEG() zur Erzeugung
CREATE OBJECT r_beleg TYPE zdp_cl_fact_konbelein.
von Belegen. In der abstrakten Factory wird der Methodenrahmen ENDMETHOD.
der Methode ERZEUGE_BELEG() definiert. Diese Methode wird in den ENDCLASS.
konkreten Factory-Klassen so ausimplementiert, dass die Belegob-
jekte erzeugt werden können. CLASS zdp_cl_fact_konerbaus DEFINITION
PUBLIC
CLASS zdp_cl_fact_erbauer DEFINITION INHERITING FROM zdp_cl_fact_erbauer
PUBLIC FINAL
ABSTRACT CREATE PUBLIC.
CREATE PUBLIC. PUBLIC SECTION.

PUBLIC SECTION. METHODS erzeuge_beleg

METHODS erzeuge_beleg REDEFINITION.
RETURNING PROTECTED SECTION.
VALUE(r_beleg) TYPE REF TO zdp_cl_fact_beleg. PRIVATE SECTION.
PROTECTED SECTION. ENDCLASS.
PRIVATE SECTION.
ENDCLASS. CLASS zdp_cl_fact_konerbaus IMPLEMENTATION.
METHOD erzeuge_beleg.
Listing 3.11 Factory Pattern – Definition der abstrakten Factory-Klasse
CREATE OBJECT r_beleg TYPE zdp_cl_fact_konbelaus.

86 87
3 Erzeugungsmuster Factory Pattern 3.2

ENDMETHOD. PUBLIC SECTION.

ENDCLASS. DATA lt_erbauer TYPE TABLE OF REF TO zdp_cl_fact_erbauer.
METHODS start.
Listing 3.12 Factory Pattern – Definition der konkreten Erbauerklassen
PROTECTED SECTION.
PRIVATE SECTION.
Ausführende Um das Pattern ausführen zu können, wird eine weitere ABAP-Klasse ENDCLASS.
Klasse benötigt. Dieser Quellcode wird letztlich in die Anwendung, die das
Factory Pattern beinhaltet, implementiert und sorgt für eine zusätzli- CLASS zdp_cl_fact_applikation IMPLEMENTATION.
METHOD start.
che Kapselung. Diese Kapselung trägt zu einer besseren Standardisie-
DATA: lo_erbauer TYPE REF TO zdp_cl_fact_erbauer.
rung der Objekte bei, die die Anwendung erzeugen kann. Zusätzlich DATA: lt_erbauer TYPE TABLE OF REF TO zdp_cl_fact_erbauer.
wird aufgrund der Kapselung der einzelnen Klassen die Robustheit DATA: lo_konkreter_erbauer_ein TYPE REF TO
der Entwicklung deutlich erhöht. Dies führt dazu, dass sich ein mög- zdp_cl_fact_konerbein.
DATA: lo_konkreter_erbauer_aus TYPE REF TO
licher Fehler in der Anwendung zum einen deutlich schneller ein-
zdp_cl_fact_konerbaus.
grenzen lässt, um den Fehler zu beheben, und zum anderen auch DATA: lo_beleg TYPE REF TO zdp_cl_fact_beleg.
nicht unbedingt gleich die ganze Anwendung stilllegt. Der Quellcode DATA: class_name TYPE abap_typename.
dieser kapselnden Klasse ZDP_CL_FACT_APPLIKATION beinhaltet die
Methode START(), über die das Entwurfsmuster angesteuert und die FIELD-SYMBOLS <fs> TYPE any.

Erzeugung der Objekte gestartet wird.

CREATE OBJECT lo_konkreter_erbauer_ein.
Tabelle Zu Beginn werden einige Variablen deklariert, die später für die Ver- APPEND lo_konkreter_erbauer_ein TO lt_erbauer.
LT_ERBAUER arbeitung benötigt werden. Dabei ist die Tabelle LT_ERBAUER hervor-
CREATE OBJECT lo_konkreter_erbauer_aus.
zuheben, die alle Objekte der konkreten Erbauerklassen enthält. APPEND lo_konkreter_erbauer_aus TO lt_erbauer.
Diese Tabelle wurde mit dem Referenztyp der Superklasse ZDP_CL_
FACT_ERBAUER deklariert, was bedeutet, dass alle Objekte, die von der LOOP AT lt_erbauer ASSIGNING <fs>.
Superklasse geerbt haben, in der ausführenden Klasse hinzugefügt DATA:
lr_describer TYPE REF TO cl_abap_typedescr,
werden können. Durch das Durchlaufen dieser Tabelle LT_ERBAUER
lv_cls_absolute_name TYPE abap_abstypename.
in einer Schleife können wir über den Klassennamen prüfen, um lr_describer = cl_abap_refdescr=>
welchen konkreten Erbauer es sich bei dem Objekt handelt. In dieser describe_by_object_ref( <fs> ).
Schleife ruft die ausgewählte Erbauerklasse auch ihre Erzeugungsme- lv_cls_absolute_name = lr_describer->absolute_name+7.
CASE lv_cls_absolute_name.
thode ERZEUGE_BELEG() auf, die dann die einzelnen Belege erzeugt.
WHEN 'ZDP_CL_FACT_KONERBEIN'.
Bei der Ausgabe können Sie sehen, dass über die konkrete Erbauer- WRITE: / 'Einbuchungsbeleg erzeugt '.
klasse das Belegobjekt, also der Einbuchungs- oder Ausbuchungsbe- WHEN 'ZDP_CL_FACT_KONERBAUS'.
leg, erzeugt wurde. WRITE: / 'Ausbuchungsbeleg erzeugt'.
ENDCASE.
In der Variable LR_DESCRIBER werden die Objekteigenschaften, die über lo_erbauer = <fs>.
den Befehl CL_ABAP_REFDESCR=>DESCRIBE_BY_OBJECT_REF( <FS> ) lo_beleg = lo_erbauer->erzeuge_beleg( ).
aus dem Objekt ausgelesen werden, vorgehalten. In unserem Beispiel WRITE: / 'Auftrag - ',lv_cls_absolute_name.
ENDLOOP.
lesen wir den absoluten Klassennamen über den Ausdruck LR_
ENDMETHOD.
DESCRIBER->ABSOLUTE_NAME+7 aus. ENDCLASS.

CLASS zdp_cl_fact_applikation DEFINITION Listing 3.13 Factory Pattern – Definition der Hauptausführungsklasse, d. h. der
PUBLIC FINAL Applikationsklasse
CREATE PUBLIC.

88 89
3 Erzeugungsmuster
Aufruf im Zur Verwendung des Factory Patterns müssen wir im letzten Schritt
ABAP-Report die Applikationsklasse ZDP_CL_FACT_APPLIKATION über den zu
Beginn definierten ABAP-Report ZDP_AR_ERZ_FACTORY aufrufen. Dies
erfolgt über folgenden Quellcode:
REPORT zdp_ar_erz_factory.
DATA lo_app TYPE REF TO zdp_cl_fact_applikation.
CREATE OBJECT lo_app.
lo_app->start( ).
Listing 3.14 Factory Pattern – Aufruf im ABAP-Report
Wird das in unserem Beispiel implementierte Factory Pattern in
einem ABAP-Report gestartet, werden durch das Durchlaufen der
LOOP AT-Schleife die einzelnen Erbauer initialisiert. Durch den Auf-
ruf der Erzeugungsmethoden wird eine Ausgabe erzeugt, anhand
derer Sie erkennen können, wie dieses Entwurfsmuster arbeitet
(siehe Abbildung 3.9). Bei der Prüfung des von der ersten konkreten
Erbauerklasse zu erzeugenden Objekts wird die erste Ausgabe
erzeugt. Dabei wird anhand des absoluten Klassennamens des
Objekts erkannt, welches der Objekte erzeugt wurde. Wie auch bei
der Applikationsklasse ZDP_CL_FACT_APPLIKATION gibt es hierfür eine
Standardklasse CL_ABAP_REFDESCR von SAP. In unserem Beispiel kön-
nen wir auf diese Weise ableiten, welcher Beleg erzeugt wurde.
Das Ergebnis dieser Implementierung erhalten Sie durch die Ausfüh-
rung des ABAP-Reports ZDP_AR_ERZ_FACTORY über Transaktion SE38.
Dabei wird folgende Ausgabe angezeigt:
Abbildung 3.9 Factory Pattern – Reportausgabe
3.2.5 Evaluation
Einsatzgründe Das Factory Pattern bietet wie das Builder Pattern erhebliche Vor-
teile bei der Erzeugung von Objekten. Sechs entscheidende Faktoren
sprechen dafür, dieses Pattern zu nutzen:
90
Factory Pattern 3.2
왘 Kapselung
Durch das Factory Pattern können konkrete Klassen abgeschirmt
werden, sodass Entwickler die internen Klassen nicht verwenden
bzw. Objekte damit erzeugen können. Dadurch werden die
Robustheit und Sicherheit der Anwendung verbessert.
왘 Konsistenz
Durch die Kapselung kann außerdem die Konsistenz der Daten
sichergestellt werden, wodurch sich unterscheiden lässt, welche
Daten zur eigentlichen Factory-Klasse und welche zum konkreten
erzeugenden Objekttyp (z. B. Beleg, Auftrag) gehören.
왘 Flexibilität
Die zu erzeugenden Objekte können sehr einfach durch andere
Objekte ausgetauscht werden.
왘 Abstraktion
Durch die Abstraktion in der Superklasse können die Factory- und
Erbauerklassen einfach und schnell erweitert werden. Dazu müs-
sen nur die Factory-Schnittstelle und die konkrete Factory-Klasse
erzeugt werden, um das Entwurfsmuster um einen zusätzlichen
Objekttyp zu erweitern.
왘 Wiederverwendbarkeit
Durch diese Flexibilität und Abstraktion ist das Factory Pattern
leicht wiederverwendbar. Jedes beliebige Produkt jeder Produkt-
familie kann mithilfe des Patterns sehr einfach erzeugt werden.
Die zu erzeugenden Produkte können in einem anderen Kontext
einfach durch andere ausgetauscht werden.
왘 Einfachheit
Das komplette Factory Pattern kommt sowohl aufseiten des Clients
als auch aufseiten der Factory-Klasse mit nur wenig Code aus.
Das Factory Pattern hat in bestimmten Fällen aber auch Nachteile. Nachteile
Sollen mit diesem Pattern Produkte erzeugt werden, die nicht zur
ursprünglichen Produktfamilie gehören, muss die Schnittstelle der
abstrakten Factory-Klasse vollständig angepasst werden bzw. eine
neue konkrete Factory-Klasse entwickelt und der abstrakten Factory-
Klasse durch Methoden bekannt gemacht werden.
Häufig stellt sich bei der Konzeption einer Anwendung die Frage, ob Builder vs.
zur Erzeugung von Objekten besser das Builder oder das Factory Pat- Factory Pattern
tern verwendet werden sollte. In der Regel erweist sich die Verwen-
91
3 Erzeugungsmuster Singleton Pattern 3.3

dung des Factory Patterns als vorteilhafter. Bei der Umsetzung des
Builder Patterns muss nur der konkrete Erbauer bekannt sein, um
mit diesem Entwurfsmuster Objekte zu erzeugen. Bei der Verwen-
dung des Factory Patterns hingegen müssen alle Factory-Objekte
bekannt sein, um Objekte zu erzeugen. Dies stellt bei einfachen, aber
auch komplexeren Anwendungen kein Problem dar.
Um ein Builder Pattern zu verwenden, sollten die zu erzeugenden
Produkte die gleiche Basis haben, d. h., es gibt eine gemeinsame
Superklasse, die alle Standardinformationen enthält und von der die
Produkte alle erben. Mit dem Factory Pattern können hingegen sehr
einfach ganz unterschiedliche Objekte, die nicht über eine gemein-
same Superklasse miteinander verbunden sind, erzeugt werden. Die-
ser Vorteil kommt vor allem bei Verwendung der abstrakten Factory
deutlich zum Tragen.
3.3 Singleton Pattern
Auch das Singleton Pattern (Einzelstück-Entwurfsmuster) gehört zu
den GoF-Mustern. Es wird eingesetzt, um die Instanziierung einer
konkretes Objekt instanziieren lässt. Durch weitere Instanziierungen
(also weitere Aufrufe der Methode erhalte_instanz()) wird immer
das gleiche Objekt zurückgegeben.
Die Verwendung des Singleton Patterns kann in SAP-Anwendungen
vorteilhaft sein, da es sowohl in ABAP als auch in Web Dynpro ABAP
den Ansatz der globalen Variablen nicht so gibt, wie man ihn aus
anderen Programmiersprachen kennt.
Durch das Singleton-Pattern wird in ABAP und Web Dynpro ABAP
ein ähnlicher Ansatz wie der der globalen Variablen zur Verfügung
gestellt.
Durch die Verwendung des Singleton Patterns erhalten Sie dasselbe
Objekt einer Klasse immer wieder, es kann statisch ausgelesen wer-
den, und Sie können es direkt weiterverarbeiten. Es wird nur eine
Instanz eines Objekts erzeugt und sichergestellt, dass auch nur eine
Instanz verwendet wird.
3.3.2 Ansatz und Lösung
In dem Klassendiagramm in Abbildung 3.10 haben wir den Aufbau Singleton-Klasse

Klasse auf genau eine Instanz zu beschränken. des Singleton Patterns skizziert. Das Pattern enthält eine einzige
Klasse Singleton. In dem UML-Klassendiagramm stellt der Client die
In der SAP-Buchhaltung kann das Singleton Pattern z. B. dazu ver- Anwendungsklasse dar bzw. die Methode, wie diese Klasse an unter-
wendet werden, ein Objekt, in dem allgemeine Informationen wie schiedlichen Stellen in einer Anwendung integriert werden kann.
Buchungskreise und Kontenpläne zum Auslesen bereitstehen, für
alle Klassen zur Verfügung zu stellen – so ähnlich wie eine globale
Variable. Auf dieses Objekt kann jede Klasse in der Anwendung Client Singleton
zugreifen und Informationen für alle Mitverwender zentral in dem - instanz :singleton
+ operation() «verwendet»
Objekt ablegen. Beachten Sie jedoch, dass der Einsatz dieses Patterns
nicht als Alternative zu globalen Variablen dienen sollte, sondern als + erhalte_instanz() :singleton
- singleton()
Lösung für die Probleme, die durch den Einsatz von globalen Varia-
blen entstehen können. Unter diese Probleme fallen z. B. unbeab-
sichtigte Variablenänderungen, Mehrfachreferenzen auf ein Objekt,
operation(){
eine schlechtere Wiederverwendbarkeit und Mehraufwand beim
Testen. s = singleton.erhalte_instanz()

}
3.3.1 Problem
Abbildung 3.10 Singleton Pattern – UML-Klassendiagramm
Singuläres Objekt Durch die Verwendung des Singleton Patterns in einer Anwendung
können Sie sicherstellen, dass sich aus einer Klasse immer nur ein

92 93
3 Erzeugungsmuster Singleton Pattern 3.3

Methode Die Singleton-Klasse besitzt das private Attribut instanz, das das ein-
erhalte_instanz() zige instanziierte Objekt der Singleton-Klasse beinhaltet. In dieser erhalte_instanz() erhalte_instanz()

Klasse gibt es neben dem Konstruktor nur eine wichtige Methode,

die Methode erhalte_instanz(). Beim Erzeugen der Klasse in ABAP Anwender Singleton Anwender

erzeugt der Konstruktor ein Objekt und speichert es im privat defi-

nierten Attribut der Klasse ab, dem Attribut instanz. Durch den Ini- Singleton@ 50A1 Singleton@ 50A1

tialisierungsaufruf der Methode erhält man dann das intern abge-

Abbildung 3.11 Singleton Pattern – Ablauf
legte Objekt der Klasse zurück.

Wird das Objekt erneut aufgerufen, kommt die Methode erhalte_

3.3.3 Einsatzbeispiele
instanz() zum Einsatz. Diese Methode gibt das Objekt der Klasse
Das Singleton Pattern wird sehr oft in Kombination mit dem Façade Kombination mit
aus dem internen Attribut zurück. Ist die Klasse zuvor noch nicht ini-
Pattern verwendet, das wir Ihnen in Abschnitt 4.4 vorstellen. Das Façade Pattern
tialisiert worden, wird das Objekt der Klasse erzeugt und intern in
Façade Pattern benötigt in vielen Fällen immer wieder das gleiche
dem Attribut instanz abgelegt. Dieses Objekt erhält dann der
Objekt. Dies wird durch das Singleton Pattern realisiert.
Anwender zurück.
Bei der Verwendung in einem gewachsenen System, aber auch bei Anti Pattern
Das Singleton Pattern können Sie an jeder Stelle einer Software ein-
der Verwendung als globale Variable wird das Singleton Pattern häu-
setzen, um Objekte über die Methode erhalte_instanz() aufzuru-
fig auch als Anti Pattern bezeichnet, weil es in diesen Fällen eher
fen. Sie sollten jedoch immer prüfen, ob die Informationen und
nachteilige Auswirkungen hat. Die Verwendung als globale Variable
Objekte zentral über ein eindeutiges Objekt zur Verfügung gestellt
führt z. B. zum Problem der Nebenläufigkeit. Wenn mehrere Instan-
werden sollen. Ist dies der Fall, kann diese Anforderung für den Ein-
zen eines Programms gleichzeitig ablaufen, haben diese beim Einsatz
satz des Singleton Patterns sprechen. Ein sinnvoller Einsatzbereich
globaler Variablen immer nur Zugriff auf den momentan gültigen
des Entwurfsmusters ist es z. B., wenn eine Information an unter-
Wert der Variablen, auch wenn dieser Wert sich z. B. auf der Daten-
schiedlichen Stellen benötigt wird. Diese Information kann durch
bank ändert. Beim Singleton Pattern wird allen Instanzen des Pro-
den Einsatz des Singleton Patterns zur Laufzeit geändert werden.
gramms derselbe Wert bereitgestellt, auch wenn dieser während der
Ablauf In Abbildung 3.11 haben wir den zeitlichen Ablauf des Erzeugungs- Laufzeit eine Änderung erfahren hat. Alle Instanzen nutzten also das
prozesses mithilfe des Singleton Patterns veranschaulicht. Der Client gleiche Objekt über die Methode erhalte_instanz().
ruft die statische Methode erhalte_instanz() der Singleton-Klasse
Ob die Verwendung des Singleton Patterns sinnvoll ist, hängt davon
auf und erhält die Referenz des Objekts sowie die Objektspeicher-
ab, ob die Systeme durch die Globalisierung der Objekte beim
adresse, in diesem Fall 50A1, zurück. Ruft ein weiterer Anwender
Anwenden des Entwurfsmusters effizienter werden oder nicht. Wird
nochmals diese Methode auf, erhält dieser das exakt gleiche Objekt
dieses Entwurfsmuster in eine Anwendung implementiert und nur
mit der gleichen Referenz zurück. Anwender 1 und 2 können auch
einmal verwendet, entsteht dadurch kein Mehrwert für die Entwick-
verschiedene Programmabschnitte sein, die in einer Anwendung
ler und die Performance.
implementiert wurden. Der SAP NetWeaver Application Server
ABAP unterstützt diesen Prozess nur bei einem Anwender und meh- In ABAP und Web Dynpro wird dieses Entwurfsmuster sehr oft Beispiel:
reren Programmabschnitten. Ein softwareübergreifendes Variablen- angewendet, weil dadurch viele Laufzeitvariablen erfasst und dann Data Store Objects

system kann leider nur durch Tabellen oder mithilfe ähnlicher Work- zwischengespeichert werden können. Ein häufiger Verwendungs-
arounds abgebildet werden. In ABAP gibt es dazu sogenannte Shared zweck besteht z. B. im Kontext zentral gespeicherter Einstellungen.
Objects, die immer für einen Benutzer in einer Session zur Verfügung Dabei werden zentrale Data Store Objects (DSO) auf der Datenbank-
stehen. schicht im System angelegt, in denen alle wichtigen Parameter einer

94 95
3 Erzeugungsmuster Singleton Pattern 3.3

Anwendung konfiguriert werden können. In solchen DSOs sollten vorhanden ist, wird dies automatisch erzeugt und erst danach dem
nur Bewegungsdaten gespeichert werden. Andere Informationen Anwender zurückgegeben.
sollten in Datenbanktabellen abgespeichert werden.

In dieser Anwendung kommt nun das Singleton Pattern zum Einsatz. 3.3.4 Umsetzung in ABAP
Es lädt alle Parameter beim Aufruf der Anwendung und speichert Zunächst wird ein ABAP-Report benötigt, den Sie in Transaktion
diese intern als eigenes Objekt ab. So kann bei einem erneuten Auf- SE38 erzeugen können:
ruf der Parameter viel schneller auf diese Variablen zugegriffen wer-
REPORT zdp_ar_erz_singleton.
den, als wenn man bei jedem Aufruf auf die Datenbankschicht
zugreifen und die Parameter dort über eine SELECT-Anweisung abru- In diesem ABAP-Report rufen wir später die Entwurfsmusterimple-
fen müsste. mentierung auf, in der verschiedene Klassen realisiert sind.

Beispiel: Ein weiteres Beispiel wäre eine unternehmensinterne Web-Dynpro- Im ersten Schritt wird die Klasse ZDP_CL_SING_SINGLETON erzeugt Singleton-Klasse
Artikeldefinition (siehe Listing 3.15). Die einzige Methode dieser Klasse, ERHALTE_ implementieren
Anwendung, über die unterschiedliche Artikel, z. B. Büromateria-
lien, bestellt werden können. Diese werden zunächst definiert, und INSTANZ(), gibt das initialisierte Objekt zurück, das in der Klasse
anschließend wird ein Bestellformular ausgegeben. Das Singleton gespeichert wurde. Ist die Klasse noch nicht initialisiert worden,
Pattern kann hier dazu eingesetzt werden, die verschiedenen Artikel wird automatisch ein neues Objekt der Klasse erzeugt und in das
in der Singleton-Klasse in einer Objektliste als Attribute der Klasse zu interne Attribut LO_INSTANZ abgespeichert.
sammeln. Auf diese zentrale Liste kann jede Klasse zugreifen und hat CLASS zdp_cl_sing_singleton DEFINITION
so alle aktuellen Artikel zur Verfügung, die als Objekt bereits zu der PUBLIC FINAL
Liste hinzugefügt worden sind. CREATE PUBLIC.
PUBLIC SECTION.
Als Programmierer müssen Sie so nicht umständlich den Web-Dyn- METHODS constructor.
pro-Kontext verwenden, um alle Details der Artikel abzuspeichern; CLASS-METHODS erhalte_instanz
RETURNING
die Anwendung kann daher viel einfacher umgesetzt werden. Statt-
VALUE(r_instanz) TYPE REF TO zdp_cl_sing_singleton.
dessen sammeln Sie alle Informationen zu den Artikeln als Objekte PROTECTED SECTION.
in der Tabelle in der Singleton-Klasse. Beim Weitergeben der Bestel- PRIVATE SECTION.
lung, also des Singleton-Objekts, das über die Methode erhalte_ CLASS-DATA lo_instanz TYPE REF TO zdp_cl_sing_singleton.
ENDCLASS.
instanz() ausgelesen werden kann, können Sie die Objekte der
internen Liste einfach abrufen und verarbeiten. Das Hinzufügen der CLASS zdp_cl_sing_singleton IMPLEMENTATION.
Artikel in das Singleton-Objekt kann durch diesen Ansatz an ver- METHOD constructor.
schiedenen Stellen im Quellcode flexibel erfolgen. ENDMETHOD.
METHOD erhalte_instanz.
Mehrfach- Als Anwendungszweck besonders hervorzuheben ist die Verhinde- IF lo_instanz IS INITIAL.
instanzen rung von Mehrfachinstanzen von Objekten. Dies kann zwar theore- CREATE OBJECT lo_instanz.
verhindern ENDIF.
tisch auch über statische Attribute realisiert werden. Durch das Single-
r_instanz = lo_instanz.
ton Pattern wird jedoch verhindert, dass mehrere Objekte einer ENDMETHOD.
Klasse erzeugt werden. ENDCLASS.

Null-Referenz Darüber hinaus kann auch eine Null-Referenz verhindert werden. Listing 3.15 Singleton Pattern – Definition und Implementierung der Singleton-
Klasse
verhindern Wenn bei einem Zugriff auf das Entwurfsmuster noch kein Objekt

96 97
3 Erzeugungsmuster
Klasse zum Aufruf Um das Singleton Pattern verwenden zu können, implementieren
des Patterns wir noch die Klasse ZDP_CL_SING_APPLIKATION. Dies ist die Client-
Klasse, die definiert, wie dieses Entwurfsmuster später in einer
Anwendung implementiert werden kann. Alternativ ist es allerdings
auch möglich, diese Klasse wegzulassen und den Quellcode direkt in
den ABAP-Report zu schreiben.
Die Klasse ZDP_CL_SING_APPLIKATION dient in unserem Beispiel zur
Verdeutlichung, wie der Aufruf in einer Klasse ihres Reports imple-
mentiert werden kann. Die Klasse beinhaltet die Methode START(),
die das Entwurfsmuster aufruft (siehe Listing 3.16). Um zu zeigen,
dass es sich bei den erzeugten Objekten immer um das gleiche
Objekt handelt, werden die beiden Objekte LO_OBJEKT1 und LO_
OBJEKT2 abgespeichert und dann miteinander verglichen.
CLASS zdp_cl_sing_applikation DEFINITION
PUBLIC
FINAL
CREATE PUBLIC.
PUBLIC SECTION.
METHODS start.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zdp_cl_sing_applikation IMPLEMENTATION.
METHOD start.
DATA: lo_objekt1 TYPE REF TO zdp_cl_sing_singleton.
DATA: lo_objekt2 TYPE REF TO zdp_cl_sing_singleton.
lo_objekt1 = zdp_cl_sing_singleton=>erhalte_instanz( ).
lo_objekt2 = zdp_cl_sing_singleton=>erhalte_instanz( ).
IF lo_objekt1 = lo_objekt2.
WRITE: / 'Das Objekt hat die gleiche Instanz.'.
ENDIF.
ENDMETHOD.
ENDCLASS.
Listing 3.16 Ausführung des Singleton-Entwurfsmusters
Methode START Um den ABAP-Report ZDP_AR_ERZ_SINGLETON ausführen zu können,
aufrufen sehen wir die in Listing 3.17 aufgeführtem Codezeilen in dem ABAP-
Report vor.
98
Singleton Pattern 3.3
REPORT zdp_ar_erz_singleton.
DATA lo_app TYPE REF TO zdp_cl_sing_applikation.
CREATE OBJECT lo_app.
lo_app->start( ).
Listing 3.17 Singleton Pattern – Aufruf im ABAP-Report
Das Ergebnis dieser Implementierung erhalten Sie durch die Ausfüh-
rung des ABAP-Reports ZDP_AR_ERZ_SINGLETON über Transaktion
SE38. Dabei wird die Ausgabe wie in Abbildung 3.12 angezeigt:
Abbildung 3.12 Singleton Pattern – Reportausgabe
Die Prüfung, ob die Objekte LO_OBJEKT1 und LO_OBJEKT2, die in der
Klasse ZDP_CL_SING_APPLIKATION erzeugt werden, gleich sind, verlief
erfolgreich. Diese Objekte haben die gleiche Referenz, und daher ist
auch ihr Inhalt komplett identisch.
3.3.5 Evaluation
Das Singleton Pattern kann sehr vielseitig und auch im Rahmen der
Implementierung anderer Erzeugungsmuster verwendet werden. Es
hilft Entwicklern dabei, Aufgaben wie das Schreiben einer Protokoll-
datei oder das Durchlaufen von Warteschleifen durch mehrere Pro-
zesse zu vereinheitlichen. Durch das Entwurfsmuster kann einfach
immer das gleiche Objekt für die entsprechende Aufgabe bereitge-
stellt und verwendet werden. Was für ein Objekt das ist, ist abhängig
vom Anwendungsfall.
Globale Variablen sind bei der Anwendungsentwicklung immer ein Globale Variablen
wichtiges Thema, um Informationen zentral und für alle Klassen,
Methoden und Objekte zur Verfügung zu stellen. Das Singleton Pat-
tern verfolgt einen objektbasierten Ansatz zur Verwendung globaler
Variablen. Es kann sehr einfach klassenübergreifend verwendet wer-
den, ohne dabei spezielle ABAP-Konstrukte verwenden zu müssen,
um es verfügbar zu machen. Diese ABAP-Konstrukte wären sehr auf-
wendig und fehleranfällig in der Implementierung.
99
3 Erzeugungsmuster
Vorteile Die Vorteile des Singleton Patterns lassen sich wie folgt zusammen-
fassen:
왘 Einfachheit
Eine Singleton-Klasse ist sehr einfach und schnell entwickelt und
hat gegenüber den globalen Variablen insofern einen erheblichen
Vorteil, als sie flexibel erweiterbar und vielfältiger einsetzbar ist.
Neben Variablen können auch Objekte in der Singleton-Klasse
abgespeichert werden. Darüber hinaus ist dieses Entwurfsmuster
in der Anwendung besser und übersichtlicher handhabbar, als es
globale Variablen sind.
Im Kundennamensraum erhalten Sie durch die Verwendung die-
ses Entwurfsmusters einen deutlich übersichtlicheren ABAP-Code.
Es sind keine globalen Variablen vorhanden, die überall verwen-
det werden, sondern alle globalen Variablen sind in der Singleton-
Klasse gekapselt. Sie können z. B. zehn oder 20 globale Variablen
erstellen, die entsprechend den Namenskonventionen alle mit
dem Präfix gv anfangen. Bei der Verwendung des Singleton Pat-
terns wird dagegen nur ein Objekt angelegt, das alle globalen Vari-
ablen enthält, auf das sehr einfach z. B. über die Bezeichnung
singletonobjekt-variable1 zugegriffen werden kann.
왘 Zugriffssicherheit
Ein weiterer wichtiger Aspekt ist der Zugriffsschutz. Das Entwurfs-
muster kapselt seine eigene Erstellung in sich selbst. Dabei wird
das Objekt der Klasse instanziiert und in sich selbst abgespeichert.
Darüber hinaus kann bei einer Eingabe in die Variable standardi-
siert durch einen Methodenaufruf eine Plausibilitätsprüfung
durchgeführt werden, die prüft, ob die gesetzten Werte korrekt
sind und weiterverwendet werden können. Dies kann direkt in
dem Entwurfsmuster realisiert werden.
왘 Ableitungen
Von der Singleton-Klasse können Sie auch weitere Ableitungen
erstellen, sodass typspezifische Variablen zur Verfügung stehen,
die während der Laufzeit gefüllt werden. Erst dann wird auch ent-
schieden, welchen Datentyp sie erhalten.
Zum Beispiel sind in der Auftragsklasse die typspezifischen Varia-
blen für die Auslagerung und die Einlagerung enthalten. Während
100
Prototype Pattern 3.4
der Laufzeit kann entschieden werden, welche Objekte für diese
zwei Variablen erzeugt werden sollen. In der Definition enthalten
diese beiden Variablen generell die Definition eines Interfaces.
왘 Lazy Loading
Sie können die Erzeugung der Singleton-Klasse immer nur dann
anstoßen, wenn sie auch benötigt wird – dies nennt man auch Lazy
Loading.
Auch bei diesem Pattern gibt es Einschränkungen für die Verwend- Einschränkungen
barkeit. Wenn das Pattern in einer Anwendung zu häufig eingesetzt
wird, leidet deren Übersichtlichkeit. Dies ist vor allem beim objekt-
orientierten Programmieren in ABAP der Fall, weil dadurch das Ent-
wurfsmuster an vielen Stellen mit den gleichen Abfragen verwendet
werden kann.
Ein anderer Nachteil ist, dass bei der Anwendung des Singleton Pat-
terns unterschiedliche Klassen entstehen, die jeweils für bestimmte
Objekte gültig sind. Daher muss die Zuordnung der zu verwenden-
den Pattern-Klasse klar definiert werden, da es sonst zu Inkonsisten-
zen kommen kann. Die Transparenz und die Wartbarkeit der
Anwendung werden infolgedessen eingeschränkt.
Im Gegensatz zu anderen Entwurfsmustern sind die Möglichkeiten
zur Wiederverwertung sehr eingeschränkt. Implementieren Sie viele
unterschiedliche Singleton-Klassen, kann die Performance der
gesamten Anwendung leiden, da diese implementierten Klassen für
alle entsprechenden Objekte erzeugt und bereitgestellt werden müs-
sen.
Beim Entwurfsmuster stehen besonders die Synchronität der Daten
und die Zentralisierung an einer Stelle (Flaschenhalsprinzip) im Vor-
dergrund. Diese Prinzipien können durch das Pattern einfach und
übersichtlich umgesetzt werden.
3.4 Prototype Pattern
Das Prototype Pattern gehört ebenso wie die drei anderen vorgestell-
ten Erzeugungsmuster zu den GoF-Mustern.
101
3 Erzeugungsmuster Prototype Pattern 3.4

3.4.1 Problem
Kopie einer Das Prototype Pattern wird eingesetzt, um Objekte auf Basis von
Vorlage Vorlagen, d. h. Prototypen einer Instanz, zu erzeugen. Dabei werden
die vorhandenen Instanzen der Objekte kopiert, und das neue
Objekt wird an die neuen Bedürfnisse angepasst. Innerhalb des Pro-
totype Patterns kann nicht nur ein Objekt, sondern es können unter-
schiedlich viele Objekte kopiert werden, die dazu dem Entwurfsmus-
ter nicht bekannt sein müssen.
faces prototype_faehig benötigt. Dieses Interface stellt in den ein-
zelnen Objekten die standardisierte Methode klonen() bereit. Durch
diese Methode hat der Entwickler die Möglichkeit, das Objekt zu
duplizieren. Dieses duplizierte Objekt erhält er als Rückgabeparame-
ter von der Methode zurück.
Um das Entwurfsmuster zu initialisieren, rufen Sie die statische
Methode erhalte_instanz() der Klasse prototype_factory auf,
über die Sie das Objekt erhalten.

3.4.2 Ansatz und Lösung 3.4.3 Einsatzbeispiele

Klassendiagramm Abbildung 3.13 skizziert das Prototype Pattern in einem UML-Klas- Das Prototype Pattern kann vor allem dann gut in Anwendungen Teure
sendiagramm. Das Diagramm enthält die Klasse prototype_factory, integriert werden, wenn Neugenerierungen von Objekten sehr auf- Neuentwicklungen
die dieses Entwurfsmuster repräsentiert. Diese Klasse wird über den vermeiden
wendig, d. h. teuer, wären. Dies ist der Fall, wenn Objekte sehr viele
Singleton-Ansatz realisiert, da immer die gleiche Instanz der Klasse Abhängigkeiten haben, die bei einer vollständigen Neuerzeugung
verwendet werden kann. ebenfalls neu definiert werden müssten. Eine wichtige Vorausset-
zung für die Verwendung des Prototype Patterns ist, dass das
key:string
Ursprungsobjekt dem neuen Objekt ähnelt.
test_prototype_pattern prototype_factory
Hinter einigen Objekten können sich Hierarchien von Factory-Klas- Factory-
+ main(string[ ]) :void + erhalte_instanz(string) :prototype_faehig
sen verbergen, die parallel zueinander bzw. gegeneinander arbeiten. Hierarchien
ignorieren
Das Prototype Pattern kann die Hierarchien einfach ignorieren und
prototype_faehig
das Objekt so kopieren, dass keine neuen Hierarchien entstehen.

Ein weiterer Vorteil entsteht, wenn die Klassen – bzw. die Objekte Dynamischer
dieser Klassen – erst während der Laufzeit bekannt sind. Dank dieser Einsatz
Einlagerungsbeleg Auslagerungsantrag Umlagerungsbeleg
dynamischen Programmierweise können Sie z. B. Vorlagenobjekte
- name :string - name :string - name :string

+ klonen() :einlagerungsbeleg + klonen() :auslagerungsauftrag + klonen() :umlagerungsbeleg

erzeugen, die durch das Prototype Pattern kopiert und dann erst aus-
+ erhalte_auftrag() :string + erhalte_auftrag() :string + erhalte_auftrag() :string geprägt werden.
+ setze_auftrag_nr(string) + setze_auftrag_nr(string) + setze_auftrag_nr(string)

In SAP-Systemen wird das Prototype Pattern häufig in komplexen Beispiel:

Konstrukten angewendet. Beispiel dafür ist eine Workflow-Anwen- Workflow

dung, die unterschiedliche Stadien durchlaufen muss. So kann z. B.

Class1
- name :string
eine Auftragsvorlage dafür verwendet werden, einen speziellen Auf-
+ klonen() :antrag trag zu erstellen, z. B. einen Auftrag zur Auslagerung eines Artikels
+ erhalte_auftrag() :string
+ setze_auftrag_nr(string)
aus einem Lager, wie in unserer Beispielanwendung in Kapitel 7,
»Flexible Entwicklung einer Beispielanwendung«, beschrieben.
Abbildung 3.13 Prototype Pattern – UML-Klassendiagramm
Das Entwurfsmuster wird hier dazu eingesetzt, die Vorlage, die
durch den Entwickler definiert wurde, zu duplizieren und dadurch
Um das Prototype Pattern funktionsbereit zu machen, wird eine
den Auftragsprototyp dem Anwender für die weitere Verarbeitung
Implementierung in den unterschiedlichen Objektklassen des Inter-
zur Verfügung zu stellen. Durch die Anlage des konkreten Auftrages

102 103
3 Erzeugungsmuster Prototype Pattern 3.4

wird dann ein Workflow in der SAP-Anwendung gestartet, der letzt- METHOD erhalte_id.
lich zur Auslagerung des Artikels führt. In diesem Beispiel kann nicht r_id = me->id.
ENDMETHOD.
nur der Standardauftrag zur Erzeugung eines individuellen Auftrags
ENDCLASS.
kopiert werden, sondern auch bereits vorhandenen Aufträgen kön-
Listing 3.18 Prototype Pattern – abstrakte Prototyp-Klasse
nen abhängige Objekte, wie z. B. auszulagernde Artikel, Genehmi-
gungen oder Bearbeitungshistorien, angehängt werden.
Die Implementierung eines konkreten Prototyps findet in der eige- Konkrete
nen Klasse ZDP_CL_PTYPE_KONTYPE1 statt. Diese Klasse erbt von der Prototyp-Klasse

3.4.4 Umsetzung in ABAP abstrakten Prototyp-Klasse. Durch diese Vererbung sind die Imple-
ABAP-Report und Genau wie die bereits beschriebenen Erzeugungsmuster wird auch mentierungen der Methode ERHALTE_ID() sowie des Konstruktors in
Klassendefinition das Prototype Pattern in einem ABAP-Report ausgeführt, den Sie in der konkreten Klasse bereits vorhanden. Zusätzlich muss noch die
Transaktion SE38 anlegen: Methode DUPLIZIEREN() implementiert werden. Wie Sie in Listing
3.19 sehen, wird dabei das Objekt der Klasse zurückgegeben.
REPORT zdp_ar_erz_prototype.
CLASS zdp_cl_ptype_konptype1 DEFINITION
Das Prototype Pattern basiert auf der abstrakten Klasse ZDP_CL_ PUBLIC
PTYPE_PROTOTYPE. Diese Klasse hat zwei Methoden, die notwendig INHERITING FROM zdp_cl_ptype_prototype
sind, um Objekte zu kopieren. Im Codebeispiel in Listing 3.18 erhält FINAL
das Objekt über die Konstruktor-Methode eine eindeutige ID, die CREATE PUBLIC.
PUBLIC SECTION.
sich nicht ändert, wenn ein Objekt geklont wird. Über die Methode
METHODS duplizieren
ERHALTE_ID() kann diese ID abgefragt werden.
REDEFINITION.
CLASS zdp_cl_ptype_prototype DEFINITION PROTECTED SECTION.
PUBLIC ABSTRACT PRIVATE SECTION.
CREATE PUBLIC. ENDCLASS.
PUBLIC SECTION.
INTERFACES if_os_clone. CLASS zdp_cl_ptype_konptype1 IMPLEMENTATION.
METHODS constructor METHOD duplizieren.
IMPORTING r_prototype ?= me->if_os_clone~clone( ).
!i_id TYPE string. ENDMETHOD.
METHODS duplizieren ENDCLASS.
RETURNING Listing 3.19 Prototype Pattern – Implementierung der konkreten Prototyp-Klasse
VALUE(r_prototype) TYPE REF TO zdp_cl_ptype_prototype.
METHODS erhalte_id
Um das Prototype Pattern verwenden zu können, wird noch die wei- Klasse zum Aufruf
RETURNING des Patterns
tere Klasse ZDP_CL_PTYPE_APPLIKATION benötigt, die angibt, wie die-
VALUE(r_id) TYPE string.
PROTECTED SECTION. ses Entwurfsmuster in einer Web-Dynpro-Anwendung eingesetzt
PRIVATE SECTION. werden soll. Sie können diese Klasse allerdings auch weglassen und
DATA id TYPE string. den Quellcode direkt in den ABAP-Report schreiben.
ENDCLASS.
In der Methode START() wird zu Beginn das Objekt LO_P1 des kon-
CLASS zdp_cl_ptype_prototype IMPLEMENTATION. kreten Prototyps erstellt. Dieses Objekt hat die I_ID = 1. Wird nun
METHOD constructor. die Methode DUPLIZIEREN() aufgerufen, wird ein neues Objekt auf
me->id = i_id.
Basis des Originalobjekts erzeugt. Rufen Sie vor dem Aufrufen der
ENDMETHOD.
Methode DUPLIZIEREN() die Methode ERHALTE_ID() auf, erhalten Sie

104 105
3 Erzeugungsmuster Prototype Pattern 3.4

die aktuelle ID des Objekts. Im Beispiel aus Listing 3.20 ist dies I_ID Das Ergebnis dieser Implementierung erhalten Sie durch die Ausfüh-
= 1. Nach dem Klonen erhält das neue Objekt die gleiche ID wie das rung des ABAP-Reports ZDP_AR_ERZ_PROTOTYPE über Transaktion
ursprüngliche Objekt. SE38. Dabei wird die Ausgabe wie in Abbildung 3.14 angezeigt:

CLASS zdp_cl_ptype_applikation DEFINITION

PUBLIC
FINAL
CREATE PUBLIC.
PUBLIC SECTION.
METHODS start.
PROTECTED SECTION.
PRIVATE SECTION.
Abbildung 3.14 Prototype Pattern – Reportausgabe
ENDCLASS.

CLASS zdp_cl_ptype_applikation IMPLEMENTATION.
METHOD start.
DATA: lo_p1 TYPE REF TO zdp_cl_ptype_konptype1.
DATA: lo_c1 TYPE REF TO zdp_cl_ptype_konptype1.
DATA: lv_id TYPE string.
Die Zeilen Original-Objekt: {0} id=1 und Geklontes Objekt: {0}
id=1 werden durch den ABAP-Report ausgegeben. Man erhält also
mit jeder Referenz auf ein Objekt das gleiche Objekt, ohne dass das
ursprüngliche Objekt dazu verändert wurde.

CREATE OBJECT lo_p1

3.4.5 Evaluation
EXPORTING
i_id = 'id=1'. Das Prototype Pattern kann nur sehr begrenzt eingesetzt werden, Rapid Deployment
lv_id = lo_p1->erhalte_id( ). und zwar vor allem, um schnell einfache Lösungen zu entwickeln
WRITE: / 'Original-Objekt: {0}', lv_id. (Rapid Deployment), die z. B. für unterschiedliche Tests benötigt wer-
lo_c1 ?= lo_p1->duplizieren( ).
den. Dabei ist es nicht relevant, ob es sich um komplexe oder einfach
lv_id = lo_c1->erhalte_id( ).
WRITE: / 'Geklontes Objekt: {0}', lv_id. strukturierte Objekte handelt. Es ist jederzeit möglich, auch während
ENDMETHOD. der Laufzeit noch weitere Unterklassen zu erzeugen. So kann eine
ENDCLASS. hohe Flexibilität bei der Variation der Objekte und deren Strukturen
Listing 3.20 Prototype Pattern – Umsetzung des Entwurfsmusters in der erzielt werden. Dabei wird keine Erzeuger-Klassenhierarchie parallel
aufrufenden Klasse zu einer Klassenhierarchie der Objekte aufgebaut.

Der Nachteil des Prototype Patterns ist, dass die Kopierfunktion für Aufwand bei
Start-Methode Um den ABAP-Report ZDP_AR_ERZ_PROTOTYPE ausführen zu können,
jedes einzelne Objekt implementiert werden muss. So ist es zwar komplexen
sehen wir in Listing 3.21 aufgeführte Codezeilen im ABAP-Report Objekten
sehr schnell und einfach möglich, das Entwurfsmuster bei einzelnen
vor.
Objekten umzusetzen, bei Objekten mit sehr vielen und differieren-
REPORT zdp_ar_erz_prototype. den Unterklassen ist die Implementierung aber mit einem größeren
DATA lo_app TYPE REF TO zdp_cl_ptype_applikation.
Aufwand verbunden.
CREATE OBJECT lo_app.
lo_app->start( ).

Listing 3.21 Prototype Pattern – Aufruf im ABAP-Report

106 107
 Inhalt

Inhalt

Einleitung .................................................................................. 13

1 Einführung ............................................................... 17

1.1 Was sind Entwurfsmuster? ...................................... 18

1.1.1 Entwurfsmuster in der
Softwareentwicklung ................................. 19
1.1.2 Softwaredesign mithilfe von
Entwurfsmustern ....................................... 22
1.2 Vorteile einer entwurfsmusterbasierten Architektur 29
1.2.1 Flexibilität bei Neuanforderungen .............. 30
1.2.2 Zeitersparnis bei der Umsetzung ................ 31
1.2.3 Möglichkeiten der Parallelentwicklung ...... 33
1.2.4 Wartbarkeit der Entwicklung ..................... 35

TEIL I Entwurfsmuster in ABAP implementieren

2 Umgang mit Entwurfsmustern ............................... 39

2.1 UML-Grafiken erstellen ........................................... 39

2.1.1 Klassendiagramm ...................................... 41
2.1.2 Anwendungsfalldiagramm ......................... 43
2.1.3 Sequenzdiagramm ..................................... 45
2.2 Grundlagen der objektorientierten
Programmierung mit ABAP ..................................... 46
2.2.1 ABAP Objects ............................................ 47
2.2.2 Klassen in ABAP ........................................ 49
2.2.3 Programmelemente, Interfaces und
Klassen verwenden .................................... 55
2.3 Programmierbeispiele in diesem Buch ..................... 62

3 Erzeugungsmuster ................................................... 63

3.1 Builder Pattern ....................................................... 66

3.1.1 Problem .................................................... 66
3.1.2 Ansatz und Lösung .................................... 66
3.1.3 Einsatzbeispiel ........................................... 69

7
Inhalt Inhalt

3.1.4 Umsetzung in ABAP ................................... 71 4.4 Façade Pattern ........................................................ 143

3.1.5 Evaluation .................................................. 77 4.4.1 Problem .................................................... 143
3.2 Factory Pattern ........................................................ 78 4.4.2 Ansatz und Lösung .................................... 144
3.2.1 Problem ..................................................... 79 4.4.3 Einsatzbeispiele ......................................... 147
3.2.2 Ansatz und Lösung ..................................... 80 4.4.4 Umsetzung in ABAP .................................. 151
3.2.3 Einsatzbeispiel ........................................... 83 4.4.5 Evaluation ................................................. 155
3.2.4 Umsetzung in ABAP ................................... 85
3.2.5 Evaluation .................................................. 90 5 Verhaltensmuster .................................................... 157
3.3 Singleton Pattern ..................................................... 92
3.3.1 Problem ..................................................... 93 5.1 Command Pattern ................................................... 159
3.3.2 Ansatz und Lösung ..................................... 93 5.1.1 Problem .................................................... 159
3.3.3 Einsatzbeispiele .......................................... 95 5.1.2 Ansatz und Lösung .................................... 160
3.3.4 Umsetzung in ABAP ................................... 97 5.1.3 Einsatzbeispiele ......................................... 162
3.3.5 Evaluation .................................................. 99 5.1.4 Umsetzung in ABAP .................................. 163
3.4 Prototype Pattern .................................................... 101 5.1.5 Evaluation ................................................. 167
3.4.1 Problem ..................................................... 102 5.2 Interpreter Pattern .................................................. 169
3.4.2 Ansatz und Lösung ..................................... 102 5.2.1 Problem .................................................... 169
3.4.3 Einsatzbeispiele .......................................... 103 5.2.2 Ansatz und Lösung .................................... 170
3.4.4 Umsetzung in ABAP ................................... 104 5.2.3 Einsatzbeispiele ......................................... 172
3.4.5 Evaluation .................................................. 107 5.2.4 Umsetzung in ABAP .................................. 174
5.2.5 Evaluation ................................................. 181
5.3 Iterator Pattern ....................................................... 182
4 Strukturmuster ........................................................ 109
5.3.1 Problem .................................................... 183
4.1 Model View Controller ............................................ 110 5.3.2 Ansatz und Lösung .................................... 183
4.1.1 Problem ..................................................... 111 5.3.3 Einsatzbeispiele ......................................... 185
4.1.2 Ansatz und Lösung ..................................... 111 5.3.4 Umsetzung in ABAP .................................. 186
4.1.3 Einsatzbeispiele .......................................... 114 5.3.5 Evaluation ................................................. 193
4.1.4 Umsetzung in ABAP ................................... 116 5.4 Mediator Pattern .................................................... 194
4.1.5 Evaluation .................................................. 120 5.4.1 Problem .................................................... 195
4.2 Adapter Pattern ....................................................... 121 5.4.2 Ansatz und Lösung .................................... 195
4.2.1 Problem ..................................................... 121 5.4.3 Einsatzbeispiele ......................................... 197
4.2.2 Ansatz und Lösung ..................................... 122 5.4.4 Umsetzung in ABAP .................................. 198
4.2.3 Einsatzbeispiele .......................................... 125 5.4.5 Evaluation ................................................. 203
4.2.4 Umsetzung in ABAP ................................... 125 5.5 Observer Pattern .................................................... 204
4.2.5 Evaluation .................................................. 129 5.5.1 Problem .................................................... 204
4.3 Composite Pattern ................................................... 130 5.5.2 Ansatz und Lösung .................................... 204
4.3.1 Problem ..................................................... 130 5.5.3 Einsatzbeispiele ......................................... 207
4.3.2 Ansatz und Lösung ..................................... 130 5.5.4 Umsetzung in ABAP .................................. 207
4.3.3 Einsatzbeispiele .......................................... 131 5.5.5 Evaluation ................................................. 212
4.3.4 Umsetzung in ABAP ................................... 134
4.3.5 Evaluation .................................................. 142

8 9
Inhalt Inhalt

5.6 State Pattern ........................................................... 212

7 Flexible Entwicklung einer Beispielanwendung ..... 287
5.6.1 Problem ..................................................... 213
5.6.2 Ansatz und Lösung ..................................... 213 7.1 Planung und Konzipierung der Beispiel-
5.6.3 Einsatzbeispiele .......................................... 215 anwendung ............................................................. 288
5.6.4 Umsetzung in ABAP ................................... 217 7.1.1 Berechtigungen und Layoutsteuerung ........ 290
5.6.5 Evaluation .................................................. 222 7.1.2 Anwendungsarchitektur ............................. 292
5.7 Strategy Pattern ....................................................... 223 7.2 Implementierung der Beispielanwendung ............... 295
5.7.1 Problem ..................................................... 224 7.2.1 Allgemeine Elemente für die
5.7.2 Ansatz und Lösung ..................................... 225 Beispielanwendung ................................... 296
5.7.3 Einsatzbeispiele .......................................... 226 7.2.2 Schichtenmodell (Model View Controller) 299
5.7.4 Umsetzung in ABAP ................................... 227 7.2.3 Auftragserzeugung (Factory Pattern) .......... 315
5.7.5 Evaluation .................................................. 230 7.2.4 Layoutsteuerung (Template Pattern) .......... 329
5.8 Template Pattern ..................................................... 231 7.2.5 Berechtigungssteuerung
5.8.1 Problem ..................................................... 232 (Command Pattern) ................................... 336
5.8.2 Ansatz und Lösung ..................................... 232 7.2.6 Sperrverfahren (Model View Controller) .... 348
5.8.3 Einsatzbeispiele .......................................... 234 7.2.7 Plausibilitätsprüfungen (Template,
5.8.4 Umsetzung in ABAP ................................... 234 Façade und Composite Pattern) ................. 359
5.8.5 Evaluation .................................................. 239 7.2.8 Anwendungslog (Singleton Pattern) ........... 372
5.9 Visitor Pattern ......................................................... 240
5.9.1 Problem ..................................................... 240
Die Autoren .............................................................................. 377
5.9.2 Ansatz und Lösung ..................................... 240
5.9.3 Einsatzbeispiele .......................................... 243
Index ........................................................................................ 379
5.9.4 Umsetzung in ABAP ................................... 244
5.9.5 Evaluation .................................................. 251

TEIL II Anwendungsentwicklung mithilfe von

Entwurfsmustern

6 Entwicklungsprojekte umsetzen ............................. 255

6.1 Vor Projektstart ....................................................... 255

6.2 Aufbau einer ganzheitlichen Architektur .................. 261
6.3 Umsetzungsmethoden ............................................. 264
6.3.1 Wasserfall-Methode ................................... 264
6.3.2 Scrum-Methode ......................................... 268
6.3.3 Kanban-Methode ....................................... 279
6.4 Review-Verfahren .................................................... 284

10 11
Index

A B
ABAP Dictionary 49, 58, 59 Backlog 270, 272
ABAP Objects 46, 48 Beck, Kent 17, 19
Abnahmetest 267 Befehl 161, 307, 321, 336
Abstract Factory Pattern 64 kapseln 159
Adapter 313 Klasse 161
Adapter Pattern 28, 33, 109, 121, Befehlsmuster 씮 Command Pattern
146, 314, 330 Beispielanwendung 288
Agent 322 Benutzeroberfläche 301, 329
Aggregat 184, 185 Benutzeroberflächenelement 씮 UI-
Aggregation 25 Element
Agilität 269 Benutzertyp 291
Akteur 44 Beobachter-Muster 204
Aktion rückgängig machen 162 Berechtigungsobjekt 291, 345
Alexander, Christopher 17 Berechtigungsprüfung 311, 326
Algorithmus 223, 231 Berechtigungssteuerung 309, 336
Alias 188 Best Practices 20
ALV 119 Besucher-Muster 158, 240
Analysephase 258 BINARY SEARCH 62
Anforderung 265 Binding 296
Anforderungsspezifikation 씮 Lasten- BPMN 40
heft Bugfixing 274
Anti Pattern 22, 95 Builder Pattern 64, 66
Anwendungsentwurf 258 Burndown Chart 274
Anwendungsfalldiagramm 43 Business Key 322
Anwendungsklasse 75 Business Layer 262
Anwendungslog 372 BW-Hierarchie 132
Anwendungslogik 307
APPEND 61
Application Layer 262 C
Arbeitsfluss 283
Architektur 17, 261 Chain Pattern 359
Architekturmodell 259 Change Management,
Artefakt 272 evolutionäres 279
Assistentenklasse 115 Changing-Parameter 58
Assoziation 25 Class Builder 49, 65
Attribut 52 Client 68, 75, 160
Instanzattribut 52 Command Pattern 158, 159, 251,
internes 97 290, 336
Konstanzattribut 52 Command-Klasse 159, 321
statisches 52 Commitment 272
UML 41 Component-Controller 112, 300
Aufrufer 160 Composite Pattern 109, 130, 168,
Auftragsnummer 289, 315 181, 308, 342, 373
Ausführungsrichtung 57 Connector 314
Context-Mapping 301

379
Index Index

Controller 112, 300, 303, 307, 309, Entwurfsmuster (Forts.) GoF-Muster 19, 27 J
336 Voraussetzungen 22 Grobentwurf 258, 261
CREATE OBJECT 119 Entwurfsproblem 20 Java 47
Cunningham, Ward 17, 19 Erbauer Johnson, Ralph 18
Cursor 씮 Iterator Implementierung 72 H
Customizing-Tabelle 315 Klasse 67
konkreter 67 Hash-Algorithmus 61 K
Erbauermuster 씮 Builder Pattern Hash-Tabelle 61
D Ereignisbehandler 321 Helm, Richard 18 Kanban-Methode 279
Erweiterungsanforderung 264 Hibernate 53 Kanban-Tafel 281
Daily Scrum 277 Erweiterungskategorie 296 Hierarchy plus Input Process Kapsel-Entwurfsmuster 씮 Façade Pat-
Data Store Object 95 Erzeugungsmuster 25, 26, 63 Output 47 tern
Datenbankschicht 313 Erzeugungsprozess 66 HIPO 47 Klasse 49
Datenbankschlüssel 322 Exportparameter 58 Hook-Methode 232 abstrakte 42, 54
Datenbanktabelle 62, 329 Hüllenklasse 씮 Adapter Pattern Attribut 52
Datenbankzugriff 313 Diagrammdarstellung 41
Datensynchronität 101 F globale 49
Datentyp I Instanziierung 51
definieren 58 Fabrik-Entwurfsmuster 씮 Factory Pat- lokale 49
UML 43 tern iDoc 123
persistente 53, 349
Deadlock 223 Façade Pattern 143, 336 Impediment Backlog 271, 275, 277
statische 51
Design 266 abstrakte Klasse 145 Implementierung 266
UML 41
Design Pattern 씮 Entwurfsmuster eine Schnittstelle 145 Importparameter 51, 58, 64
Klassenakteur 322
Designphase 262 Inbound-Plug 304
Fachbereich 256 Klassendiagramm 41
Index 60, 322
Dialogbenutzer 291 Fachkonzept 씮 Lastenheft Klassenkonstruktor 51
Direktor 68, 75 Indirektionsstufe 156
Factory Pattern 63, 78, 90, 92, 239, Klassenmuster 25, 63
Domäne 58 Infrastrukturschicht 262
292 Klonen 103
Dreischichtenmodell 114 INITIAL SIZE 61
Factory-Klasse 79, 312 Kommando 159, 311
DRY-Prinzip 32 Injection 77
abstrakte 79, 81 Kompositionsansatz 26, 157
Instanz 49
konkrete 81 Kompositummuster 씮 Composite Pat-
Instanzattribut 52
Factory-Methode 79 tern
E Fehlerbehebung 274
Instanziierung 28
konkreter Erbauer 74
Instanzmethode 53
Feinentwurf 259 Konstante 32, 58
Earned-Value-Analyse 273 Integrationstest 266
Flaschenhalsprinzip 101 Konstanzattribut 52
Einschubmethode 232 Interface 54, 123, 187, 310, 312
Flexibilität 30 Konstruktionsprozess 씮 Erzeugungs-
Einzelstück-Entwurfsmuster 씮 Single- Fliegengewicht-Muster 182
Konstante 54
prozess
ton Pattern Typ 54
Flow-Prinzip 281 Konstruktor 51
Empfänger 160 Flyweight Pattern 182
Interpreter Pattern 157, 169
Kontext 295, 300
Endlosschleife 212 Iteration 184
Framework 18 Kontextobjekt 28
Entwicklungsansatz 18 Iterator 182, 184
Funktionsbaustein 299 Kontrollfluss 26, 157
Entwicklungsprojekt 255 externer 184
Funktionstest 266
Entwicklungsumfang 255 interner 184
Entwurfsmuster 18 Klasse 188 L
Gruppe 25 G konkreter 184
Historie 18 Iterator Pattern 158, 182 Lastenheft 258, 259, 262, 266
Katalog 28 Gamma, Erich 18 IT-Spezifikation 259, 266 Laufzeitänderung 26
Kategorie 25 Gang of Four 19 Layout
klassenbasiertes 63 Geschäftslogikschicht 312 flexible Steuerung 290
objektbasiertes 63 Getter-Methode 29 Manager 329
Typ 25 GoF 19 Steuerung 329
Übersicht 26 Lazy Loading 101

380 381
Index Index

Lead-Selection 305 Objekt (Forts.) Programmiersprache, objektorien- Scrum-Methode (Forts.)

Log 씮 Protokoll instanziieren 28 tierte 19 Rollen 270
Logical Unit of Work 349 persistentes 312 Projektmanagement 255 Security Manager 344
Lösungsentwurf 258 primitives 131 Projektphase 258 Select-Anweisung 96
LUW 349 zusammengesetztes 131 Projektplan 255 Sequenzdiagramm 45, 259
Objektklasse 158 protected 51 Setter-Methode 29
Objektmuster 25, 63, 64 Protokoll 159 Shared Objects 94
M Objektorientierung 19, 46 Prototyp 102 Sichtbarkeit 42, 50
Observer Pattern 158, 204 Prototype Pattern 64, 101 Singleton Pattern 64, 92, 93, 101
Management Board 275 Online Text Repository 298 Prozess 288 Software
Mapping 322 Open SQL 313 Prüfobjekt 360 Qualität 24, 29
Mediator Pattern 158, 194, 212 Operation Prüfung 360 Verhalten 157
Mehrfachinstanz 96 ausführen 159 public 51 Softwaredesign 23, 257
Mehrsprachigkeit 298 primitive 233 Publish-Subscribe-Schnittstelle 204 Sperrobjekt 349
Meldung 299 Pull-Verfahren 205, 280 Sperrtabelle 351
rückgängig machen 162
Memento Pattern 168 Push-Verfahren 205 Sperrverfahren 348
OTR 298
Message Manager 298 Implementierung 355
Out of Scope 260
Methode 53 optimistisches 349
Einschubmethode 232 R pessimistisches 349
Instanzmethode 53 P Spezifikation, technische 256
Schnittstelle 54 Rapid Deployment 107
Sprachunterstützung 298
statische 53 PAL-Editor 303 READ TABLE INDEX 61
Sprint 276
Model 111, 300 Parallelentwicklung 18, 33 Redo 162
Backlog 273
Model View Controller 110, 204, Parameter Redundanz 18, 32, 263
Planung 275
292, 299, 348 Ausführungsrichtung 57 Refactoring 22
Retrospektive 277
Mustersprache 17 definieren 57 Remote Function Call 씮 RFC
Review 277
MVC 씮 Model View Controller Typ 58 Remote-Funktionsbaustein 49
Ziel 275
Parser 173 Report 71
Standardtabelle 61
Parser-Generator 173 Repository Browser 296
Stapelverarbeitung 131
N Persistenzdienst 321 Retest 282
State Pattern 158, 212
Persistenz-Mapping 322 Retrospektive 277
Nachrichten-ID 298 Steuerungsschicht 307
PFCG-Rolle 291 Returning-Parameter 58
Nachrichtenklasse 297, 298 Strategiemuster 씮 Strategy Pattern
Pflichtenheft 259, 266 Review 277
Nachrichtentyp 298 Strategy Pattern 158, 223
Plausibilitätsprüfung 31, 264, 359 RFC 49
Nachtest 282 Struktur 58, 59, 296
Polymorphismus 55 RFC-Aufruf 314
Namenskonvention 56 globale 59
Präsentationsschicht 111, 301 RFC-Destination 315
Navigation 303 lokale 59
Primärschlüssel 60, 322 Strukturmuster 25, 26, 109
Nebenläufigkeit 95
private 51 Superklasse 81
Null-Referenz 96
Process Model and Notation 씮 BPMN S
Nummernkreisintervall 316 Syntaxbaum 169
Product Backlog 270, 272, 273
Nummernkreisobjekt 316 SAP List Viewer 305
Product Owner 270
Schablonenklasse 235
Produkt 68, 71
Schablonenmethode 씮 Template Pat- T
Produktklasse 71
O Programmieransatz
tern
Tabelle 58
Schichtenarchitektur 114, 262, 301
Object Management Group 40 datengetriebener 47 Hash 61
Schnittstelle 292
Object Services 53, 54, 312, 321 dynamischer 53 kundeneigene 322
Scrum Master 271
Objects for State 씮 Zustandsmuster funktionsgetriebener 47 sortierte 61
Scrum Team 271
Objekt 49 objektorientierter 19, 46 Standardtabelle 61
Scrum-Methode 268
aktivieren 34 prozeduraler 47 Struktur 60
Artefakte 272
erzeugen 26 T100 299
Rituale 275

382 383
Index

Template Pattern 158, 231, 233 Viererbande 17, 19

Test 266 Vierschichtenmodell 114
Testphase 256 View 112, 300
Toolkit 79 View-Controller 112, 300, 330, 331
Top-Level-Transaktion 355 Visitor 240
Transaktion Visitor Pattern 158, 240
SE11 59 Vlissides, John 18
SE24 49, 65 Vorlage 232
SE38 71
SE80 296
SGL1 376 W
SPRO 316
Wartbarkeit 35
SU21 345
Warteschlange 159, 162
SU53 347
Wasserfallmodell 264
Traversierung, polymorphe 194
Wasserfallmodell nach Royce 267
Traversierungsschnittstelle 194
Web Dynpro Component 301
eingebettete 303
U zentrale 303
Web-Dynpro-Anwendung 301
Übergabeparameter 29 Web-Dynpro-Component 300
Übersetzung 298 Web-Dynpro-Kontext 296, 300
UI-Element 162 Wertebereich 58
UML 39, 41 Wiederherstellung 162
UML-Diagramm 41 Wiederverwendbarkeit 47
Umsetzungsmethode, agile 269 Wildwuchs 111
Undo 159, 162 Window 300, 304
Unified Message Language 씮 UML Window-Controller 300
Unique-Index 322 Work in Process 281, 283
URL 301 Workflow 281
Use-Case-Diagramm 씮 Anwendungs- Wrapper 씮 Adapter Pattern
falldiagramm Wurzelknoten 141
User Interface 262
User Story 270
Z
V Zeiger 씮 Iterator
Zentralisierung 30
Variable 58, 140 Zustand
globale 100 Abhängigkeit 213
Variante 68, 209 Änderung 213
VBA 47 Zustandsautomat 213
Verarbeitungsklasse 71 Zustandshierarchie 214
Vererbung 26 Zustandsklasse 217
Verhaltensmuster 25, 26, 157 Zustandsmuster 씮 State Pattern
Vermittler-Entwurfsmuster 씮 Media- Zustandsobjekt 28
tor Pattern

384
 Wissen aus erster Hand.
Nurgül Atilgan, Markus Straub
Entwurfsmuster in ABAP
384 Seiten, gebunden, 2. Auflage 2015
69,90 Euro, ISBN 978-3-8362-3810-6
www.sap-press.de/3881
Nurgül Atilgan ist Mitarbeiterin der T-Systems GEI GmbH
und arbeitet als SAP BI/BO Consultant im Automotive-
Sektor. In den letzten Jahren hat sie zunehmend die Rolle
der Projektmanagerin in SAP-BI- und Entwicklungsprojek-
ten übernommen. In vielen erfolgreich abgeschlossenen
Projekten konnte sie ihre Fähigkeiten und Kenntnisse in der
Projektsteuerung und -koordination unter Beweis stellen.
Markus Straub ist Mitarbeiter der T-Systems International
GmbH. Er arbeitet als BI-Architekt und -Berater in der Au-
tomobilindustrie. Sein Fokus liegt auf der Konzeption und
Implementierung von SAP-BW-/BusinessObjects-Anwen-
dungen. Die vielfältigen Erfahrungen in der Industrie und
in unterschiedlichen Einsatzbereichen zeichnen ihn aus und
bedingen sein weites Wissensspektrum.
Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne
empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte
beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstel-
lung von der E-Book-Fassung des vorgestellten Buches abweichen können.
Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nut-
zungs- und Verwertungsrechte liegen beim Autor und beim Verlag.
Teilen Sie Ihre Leseerfahrung mit uns!