ABAP OO - Factory Methode, Factory und Singleton
Was hat die Factory Methode, die Factory und der Singleton in ABAP gemeinsam? Lass es uns Schritt für Schritt in diesem Artikel herausfinden.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns verschiedene Pattern aus der objektorientierten Entwicklung an und prüfen an einem Beispiel, wie wir uns verbessern können und für was wir eigentlich die Pattern alles verwenden können. Dabei verweisen wir auch auf einige Beispiel im Standard, wo die Pattern gut sichtbar sind.
Einleitung
Implementierungspattern in der objektorientierten Entwicklung gibt es einige und so haben sehr viele auch ihren Weg in die ABAP Entwicklung gefunden. Einige Pattern, wie zum Beispiel der Iterator, trifft man auch in ABAP, ist aber eher selten, da der LOOP eine sehr starke Funktion ist und die Verarbeitung von Tabellen recht einfach funktioniert.
In diesem Artikel werden wir Stück für Stück uns verschiedene Pattern anschauen, die als Ziel haben uns eine Instanz einer Klasse zur Verfügung zu stellen, das ist auch die Gemeinsamkeit der genannten Pattern. Lass uns in den nächsten Abschnitten also direkt mit dem Thema objektorientierte Entwicklung starten.
Statische Klasse
Im ersten Schritt stellen wir eine einfache Klasse zur Verfügung, diese besitzt zwei Methoden, die wir in unserer Entwicklung verwenden. Über die Methode GET_TIMESTAMP erhalten wir den aktuellen Timestamp im Format TIMESTAMPL. Die zweite Methode SAVE_TIMESTAMP ruft die erste Methode auf und speichert den Zeitstempel in einem öffentlichen Attribut, dass aber auf READ-ONLY steht und damit nur von der Klasse geschrieben werden kann.
Implementierung
Schauen wir uns hier einmal die Implementierung der Klasse an, diese dient, als Grundlage und wir in den folgenden Schritten weiter optimiert.
CLASS zcl_bs_demo_oo_start DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
CLASS-DATA timestamp TYPE timestampl READ-ONLY.
CLASS-METHODS get_timestamp
RETURNING VALUE(result) TYPE timestampl.
CLASS-METHODS save_timestamp.
ENDCLASS.
CLASS zcl_bs_demo_oo_start IMPLEMENTATION.
METHOD get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD save_timestamp.
timestamp = get_timestamp( ).
ENDMETHOD.
ENDCLASS.
Verwendung
Wollen wir nun die Methoden der Klasse verwenden, dann schreiben wir zuerst den Namen der Klassen und führen im zweiten Schritt einen statischen Zugriff über den Fat-Arrow (=>) durch. Da wir statische Methoden (CLASS-METHODS) verwenden, müssen/können wir keine Instanz erzeugen.
zcl_bs_demo_oo_start=>save_timestamp( ).
DATA(timestamp) = zcl_bs_demo_oo_start=>timestamp.
Grundsätzlich werden solche Klassen im Bereich UTILITY eingesetzt, wo nicht erst eine Instanz erzeugt werden soll, sondern nur eine wiederverwendebare Methode genutzt wird, die auch keine Daten in der Klasse persistiert.
Bewertung
Dabei hat die Klasse aktuell mehrere Nachteile, die sie in der Nutzung einschränken. Wir können nur eine "Instanz" der Klasse haben, damit können wir sie in unserem Coding nicht mehrfach verwenden und so die Daten voneinander trennen. Das Attribut TIMESTAMP kann nur einmal gesetzt werden. Grundsätzlich werden solche Klassen in der Entwicklung genutzt, um Hilfemethoden zur Verfügung zu stellen, die keine Daten persistieren.
Herausforderung
Eine statische Klasse kann in unserer Verarbeitung für Probleme sorgen, da wir nie ihren aktuellen Zustand korrekt voraussagen können. Ist der Puffer befüllt, hat ein Prozess vorher das Objekt verwendet und sind statische Attribute teilweise befüllt? Ähnlich wie Funktionsgruppen, könnten statische Klassen in unbedachten Händen zu Probleme und Seiteneffekten führen.
Instanz
Im nächsten Schritt stellen wir die Klasse auf wiederverwendbar um, damit wir sie in unseren Läufen mehrfach verwenden können. Einzige Änderung, die wir hier durchführen müssen, ist das CLASS von den Attributen und den Methoden zu entfernen. Sonst sind keine weiteren Anpassungen nötig.
CLASS zcl_bs_demo_oo_instance DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
DATA timestamp TYPE timestampl READ-ONLY.
METHODS get_timestamp
RETURNING VALUE(result) TYPE timestampl.
METHODS save_timestamp.
ENDCLASS.
CLASS zcl_bs_demo_oo_instance IMPLEMENTATION.
METHOD get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD save_timestamp.
timestamp = get_timestamp( ).
ENDMETHOD.
ENDCLASS.
Verwendung
Damit ändert sich aber bereits die Verwendung der Klasse. Wir müssen nun zuerst eine Instanz mit NEW erzeugen, bevor wir dann die Klasse verwenden können. Der Zugriff erfolgt dann per Thin-Arrow (->) auf die Methoden und Attribute. In dem Beispiel legen wir uns eine Tabelle an, die den Zeilentyp unserer Klasse hat. In der DO Schleife erzeugen wir dann jeweils eine neue Instanz und speichern einen Zeitstempel lokal. Die Instanz übernehmen wir dann in unsere interne Tabelle und speichern so einen eigenen Stand.
DATA instances TYPE STANDARD TABLE OF REF TO zcl_bs_demo_oo_instance WITH EMPTY KEY.
DO 3 TIMES.
DATA(instance) = NEW zcl_bs_demo_oo_instance( ).
instance->save_timestamp( ).
INSERT instance INTO TABLE instances.
ENDDO.
Bewertung
Unsere Klasse arbeitet nun mit Instanzen und wir können die einzelnen Objekte wiederverwenden. Damit ist es uns möglich mehrere Werte eines Zeitstempels in unterschiedlichen Instanzen zu speichern und die Klasse mehrfach einzusetzen.
Herausforderung
Wir können nur genau eine Klasse erstellen und implementieren, wir haben aktuell also keine Möglichkeit mehrere Varianten der Klasse oder der Implementierung zu erstellen und in unserem Code zu verwenden.
Interface
Im nächsten Schritt wollen wir die Möglichkeit schaffen, dass wir die Implementierung austauschen können. Dazu erstellen wir im ersten Schritt ein Interface, den Bauplan unserer Klasse. Der Bauplan repräsentiert den öffentlichen Teil unserer Klasse, damit lagern wir alle PUBLIC Bestandteile unserer Klasse ins Interface aus.
INTERFACE zif_bs_demo_oo_interface
PUBLIC.
DATA timestamp TYPE timestampl READ-ONLY.
METHODS get_timestamp
RETURNING VALUE(result) TYPE timestampl.
METHODS save_timestamp.
ENDINTERFACE.
Entsprechend implementieren wir unsere Klasse mit dem Interface. Dabei wird über INTERFACES das Interface eingebunden und in der Methodenimplementierung taucht der Name des Interfaces im Namen der Methode auf.
CLASS zcl_bs_demo_oo_interface DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_bs_demo_oo_interface.
ALIASES timestamp FOR zif_bs_demo_oo_interface~timestamp.
ENDCLASS.
CLASS zcl_bs_demo_oo_interface IMPLEMENTATION.
METHOD zif_bs_demo_oo_interface~get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD zif_bs_demo_oo_interface~save_timestamp.
timestamp = zif_bs_demo_oo_interface~get_timestamp( ).
ENDMETHOD.
ENDCLASS.
Der Nachteil ist allerdings, dass wir nun das Attribut oder andere Methoden mit dem Namen des Interfaces aufrufen müssen, was die Abbildung innerhalb der Klasse sehr lang und unübersichtlich macht. Allerdings können wir auch innerhalb der Klasse einen ALIAS verwenden. Dieser erlaubt uns den Zugriff über den definierten Namen.
ALIASES timestamp FOR zif_bs_demo_oo_interface~timestamp.
Da wir nun ein Interface haben, wollen wir eine zusätzliche Implementierung anlegen. In diesem Fall implementieren wir das Interface leer in einer Klasse. Damit haben wir zwei Klasse, die das gleiche Interface implementieren.
CLASS zcl_bs_demo_oo_empty DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_bs_demo_oo_interface.
ENDCLASS.
CLASS zcl_bs_demo_oo_empty IMPLEMENTATION.
METHOD zif_bs_demo_oo_interface~get_timestamp.
ENDMETHOD.
METHOD zif_bs_demo_oo_interface~save_timestamp.
ENDMETHOD.
ENDCLASS.
Verwendung
In Eclipse können wir uns im Interface per F4 oder STRG + T die "Type Hierarchie" anzeigen lassen, damit erhalten wir Informationen in der Vererbungskette des Interfaces und sehen unsere beiden Klassen, die das Interface implementieren.
Verwenden wir nun die Klasse, würden wir unsere Variable über das Interface anlegen. Damit können wir alle Objekte darauf ablegen/erzeugen, die das Interface implementieren. Im Beispiel erzeugen wir jeweils die beiden Klassen, rufen unsere Speichern Methode auf und hängen die Instanzen an die gleiche Tabelle.
DATA instance TYPE REF TO zif_bs_demo_oo_interface.
DATA instances TYPE STANDARD TABLE OF REF TO zif_bs_demo_oo_interface WITH EMPTY KEY.
instance = NEW zcl_bs_demo_oo_interface( ).
instance->save_timestamp( ).
INSERT instance INTO TABLE instances.
instance = NEW zcl_bs_demo_oo_empty( ).
instance->save_timestamp( ).
INSERT instance INTO TABLE instances.
Bewertung
Mit dem Interface ist es nun zusätzlich möglich, dass wir mehrere Implementierungen mit dem gleichen Bauplan anlegen. Wir können damit verschiedenes Verhalten implementieren und zur Laufzeit unsere gewünschte Klasse erzeugen.
Herausforderung
Eine Herausforderung bei dieser Methodik gibt es allerdings noch, und zwar die Inline Deklaration. Wollen wir die Klasse verwenden, so müssen wir in der ersten Variante beim Aufruf der Methode auch das Interface übernehmen, der Methodenaufruf wird entsprechend länger. In der zweiten Variante casten wir direkt bei der Erstellung auf das Interface, um so eine Variable mit dem Typen des Interfaces zu erhalten.
DATA(interface) = NEW zcl_bs_demo_oo_interface( ).
interface->zif_bs_demo_oo_interface~save_timestamp( ).
DATA(interface_cast) = CAST zif_bs_demo_oo_interface( NEW zcl_bs_demo_oo_interface( ) ).
interface_cast->save_timestamp( ).
Beide Methoden sind relativ lang und erzeugen bei der Verwendung mehr Code, der mit der Zeit unübersichtlich werden könnte.
Factory Methode
Die Factory Methode stellt uns in der Klasse eine Methode zur Verfügung, die uns Objekt der Klasse erzeugt und in einem brauchbaren Typen zurückgibt. Dabei stellen wir die Erzeugung der Klasse auf PRIVATE, sodass Instanzen nur noch über unsere Methode erzeugt werden können. Ist unser Konstruktor vielleicht zu komplex, dann können wir mehrere Factory Methoden für die unterschiedlichen Szenarien zur Verfügung stellen.
CLASS zcl_bs_demo_oo_factory_method DEFINITION
PUBLIC FINAL
CREATE PRIVATE.
PUBLIC SECTION.
INTERFACES zif_bs_demo_oo_interface.
CLASS-METHODS create
RETURNING VALUE(result) TYPE REF TO zif_bs_demo_oo_interface.
ENDCLASS.
CLASS zcl_bs_demo_oo_factory_method IMPLEMENTATION.
METHOD create.
RETURN NEW zcl_bs_demo_oo_factory_method( ).
ENDMETHOD.
METHOD zif_bs_demo_oo_interface~get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD zif_bs_demo_oo_interface~save_timestamp.
zif_bs_demo_oo_interface~timestamp = zif_bs_demo_oo_interface~get_timestamp( ).
ENDMETHOD.
ENDCLASS.
In der Implementierung hat sich nun geändert, dass die Klasse auf CREATE PRIVATE steht und wir eine statische Methode CREATE haben, die als Ergebnis eine Instanz vom Typen des Interface zurückgibt. Eine direkte Erzeugung der Klasse ist nun nicht mehr möglich und wird vom Compiler unterdrückt.
Verwendung
Wie sieht es nun mit der Verwendung der Factory Methode aus, dazu haben wir zwei Beispiele für dich, wie wir es verwenden können. Im ersten Beispiel erzeugen wir die Instanz über die CREATE Methode, rufen die SAVE Methode auf und können danach mit der Instanz weiterarbeiten. Im zweiten Beispiel erzeugen wir eine Instanz und rufen direkt die Methode GET_TIMESTAMP auf, um einen neuen Zeitstempel zu erzeugen.
DATA(instance) = zcl_bs_demo_oo_factory_method=>create( ).
instance->save_timestamp( ).
DATA(new_timestamp) = zcl_bs_demo_oo_factory_method=>create( )->get_timestamp( ).
Bewertung
Wir arbeiten nun mit einer Instanz und erzeugen Objekte über eine zusätzliche Methode, um den richtigen Typ zurückzuerhalten. Damit ist unser Code sauber und wir müssen keine zusätzliche Variable anlegen oder die Instanz casten. Damit halten wir bereits viele Best Practices in diesem Bereich ein.
Herausforderung
Eine Herausforderung bleibt allerdings auch noch mit diesem Ansatz. Aktuell ist unsere Klasse im Quellcode hart hinterlegt, damit erzeugen wir eine Abhängigkeit von der konkreten Implementierung in ZCL_BS_DEMO_OO_FACTORY_METHOD. Wollen wir unser eigenes Objekt testen, wollen wir diese Komponente normalerweise nicht mit Testen (DOC - Dependend-On Component).
Factory
Für die Factory müssen wir eine zusätzliche Klasse implementieren, die eigentliche Factory. Die Aufgabe der Factory ist die Erzeugung von spezifischen Instanzen auf Basis der öffentlichen Beschreibung (Interface). Die Klasse ist als ABSTRACT definiert, damit von der Klasse selbst keine Instanzen erzeugt werden können. Über die CREATE Methode erzeugen wir ein Objekt vom Typ unseres Interfaces.
CLASS zcl_bs_demo_oo_factory DEFINITION
PUBLIC ABSTRACT FINAL.
PUBLIC SECTION.
CLASS-METHODS create
RETURNING VALUE(result) TYPE REF TO zif_bs_demo_oo_interface.
ENDCLASS.
CLASS zcl_bs_demo_oo_factory IMPLEMENTATION.
METHOD create.
RETURN NEW zcl_bs_demo_oo_private( ).
ENDMETHOD.
ENDCLASS.
Entsprechend müssen wir unsere Klasse nun etwas anpassen. Die CREATE Methode befindet sich nun in der Factory, damit diese aber nun Objekte von unserer Klasse erzeugen darf (PRIVATE), müssen wir die Factory als GLOBAL FRIEND hinterlegen. Unsere Klasse bleibt weiterhin auf PRIVATE, damit Objekte nur kontrolliert über die Factory erzeugt werden können.
CLASS zcl_bs_demo_oo_private DEFINITION
PUBLIC FINAL
CREATE PRIVATE
GLOBAL FRIENDS zcl_bs_demo_oo_factory.
PUBLIC SECTION.
INTERFACES zif_bs_demo_oo_interface.
ENDCLASS.
CLASS zcl_bs_demo_oo_private IMPLEMENTATION.
METHOD zif_bs_demo_oo_interface~get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD zif_bs_demo_oo_interface~save_timestamp.
zif_bs_demo_oo_interface~timestamp = zif_bs_demo_oo_interface~get_timestamp( ).
ENDMETHOD.
ENDCLASS.
Verwendung
Um nun unser Objekt zu erzeugen und zu verwenden, verwenden wir die Factory in unserem Code, die eigentliche Klasse interessiert uns damit im Moment nicht mehr. Über die Factory erzeugen wir eine Instanz mit einer spezifischen Implementierung und verwenden über das Interface alle öffentlichen Attribute und Methoden.
DATA(instance) = zcl_bs_demo_oo_factory=>create( ).
instance->save_timestamp( ).
DATA(saved_timestamp) = instance->timestamp.
Bewertung
Die eigentliche Implementierung in der Klasse ZCL_BS_DEMO_OO_PRIVATE ist durch die Factory nun entkoppelt. Liefert uns die Factory zum Beispiel eine Testimplementierung im Unit Test, zum Beispiel über einen Injektor in die Factory, dann haben wir eine testbare Umgebung geschaffen.
Herausforderung
Die größte Herausforderung in diesem Szenario ist die Verwaltung und Erzeugung der Objekte, da wir hier mindestens 3 Objekte anlegen müssen. Dafür gibt es mittlerweile auch eine automatische Lösung für die Cloud, die dir bei der Anlage unter die Arme greifen soll. Mit MIA (My IDE Actions) kannst du auf einem Paket die gewünschten Objekte anlegen.
Singleton
Im letzten Schritt implementieren wir einen Singleton. Grundsätzlich kannst du hier über ein Interface arbeiten oder direkt über die Klasse, wenn es um die Erstellung und Verwaltung geht, damit decken wir die Szenarien Instanz und Interface ab. Den Singleton stellen wir auf die Erzeugung PRIVATE ein, damit die Methode GET_INSTANCE verwendet wird. Zusätzlich haben wir ein statisches Attribut, welches eine Instanz der Klasse für uns hält.
CLASS zcl_bs_demo_oo_singleton DEFINITION
PUBLIC FINAL
CREATE PRIVATE.
PUBLIC SECTION.
DATA timestamp TYPE timestampl READ-ONLY.
CLASS-METHODS get_instance
RETURNING VALUE(result) TYPE REF TO zcl_bs_demo_oo_singleton.
METHODS get_timestamp
RETURNING VALUE(result) TYPE timestampl.
METHODS save_timestamp.
PRIVATE SECTION.
CLASS-DATA singleton TYPE REF TO zcl_bs_demo_oo_singleton.
ENDCLASS.
CLASS zcl_bs_demo_oo_singleton IMPLEMENTATION.
METHOD get_instance.
IF singleton IS NOT BOUND.
singleton = NEW zcl_bs_demo_oo_singleton( ).
ENDIF.
RETURN singleton.
ENDMETHOD.
METHOD get_timestamp.
GET TIME STAMP FIELD result.
ENDMETHOD.
METHOD save_timestamp.
timestamp = get_timestamp( ).
ENDMETHOD.
ENDCLASS.
Bei der Erzeugung der Instanz über GET_INSTANCE prüfen wir im ersten Schritt, ob es bereits eine gespeicherte Instanz gibt und geben sonst immer diese an den Aufrufer zurück.
Verwendung
In unserem Beispiel lassen wir uns eine Instanz zurückgeben und speichern den Zeitstempel. Im zweiten Schritt rufen wir die Methode erneut auf und speichern die Instanz in einer Variablen. Zum Abschluss vergleichen wir die beiden Zeitstempel miteinander, diese sollten gleich sein, da wir immer die gleiche Instanz erhalten.
DATA(save_instance) = zcl_bs_demo_oo_singleton=>get_instance( ).
save_instance->save_timestamp( ).
DATA(empty_instance) = zcl_bs_demo_oo_singleton=>get_instance( ).
IF save_instance->timestamp = empty_instance->timestamp.
ENDIF.
Schauen wir uns die beiden Variablen im Debugger an, dann zeigen sie auch auf das gleiche Objekt.
Bewertung
Der Singleton dient vor allem dazu, während der gesamten Prozesslaufzeit immer wieder die gleiche Instanz und damit die gleichen Daten zu erhalten. Damit muss eine Instanz nicht von Klasse zu Klasse gegeben werden, sondern kann immer zentral im gesamten Prozess ermittelt werden. Vorsicht allerdings, wenn der Prozess oder ein Aufrufer ein neues Objekt erwartet und nicht mit einem Singleton gerechnet hat.
Der Singleton ist damit eine Mischung aus den gezeigten Pattern, da wir eine Instanz und sehr wahrscheinlich ein Inferface verwenden und über die GET_INSTANCE Methode eine ähnliche Variante wie die Factory Methode zur Verfügung stellen. Unterschied ist allerdings, dass wir immer die gleiche Instanz in unserem Prozess erhalten.
Herausforderung
Die Herausforderung in diesem Fall ist, dass wir immer nur Objekt erzeugen können. Wir können aber auch etwas mehr Logik investieren, um über einen Parameter verschiedene Instanzen zu verwalten. Die Verwaltung bleibt trotzdem der Klasse überlassen.
Standard Beispiele
In diesem Abschnitt schauen wir uns Beispiele aus dem Standard an und wo du die verschiedenen Pattern findest. Einige Beispiele werden dir bestimmt sehr vertraut vorkommen, weil du sie bereits im Alltag nutzt.
- Statisch - Mit der Klasse CL_ABAP_CONTEXT_INFO können wir uns Systeminformationen geben lassen, die typischerweise in SYST stehen.
- Instanz - Zum Packen von Dateien kannst du die Klasse CL_ABAP_GZIP_BINARY_STREAM verwenden, die kein Interface zur Verfügung stellt, aber dafür eine Instanz.
- Interface - Eine Basis Implementierung im Bereich Application Jobs findest du mit der Klasse CL_APJ_JT_CHECK_BASE, hierbei handelt es sich eher um eine Fallback Implementierung, wenn nichts übergeben wird.
- Factory Methode - Die Factory Methode der Klasse CL_SXML_STRING_READER erzeugt ein Objekt zum Lesen von XML Streams. Der Konstruktor wurde allerdings im PUBLIC Bereich angelegt.
- Factory - Mit CL_IAM_BUSINESS_USER_FACTORY erzeugst du neue Objekte zum Lesen und Ändern von Business Usern.
- Singleton - Einen freigegebenen Singleton im Standard zu finden, ist releativ schwer und auch ein recht selten verwendetes Konzept. Mit CL_SWF_TST_CONTAINER_SINGLETON kannst du Test Container im klassischen Workflow anlegen.
Zusammenfassung
Es gibt verschiedene Ansätze, um Implementierungen durchzuführen. Jede Methode baut in den meisten Fällen auf einem Vorgänger auf und nutzt die Konzepte, um eine verbesserte Variante zur Verfügung zu stellen oder den Nutzen leicht abzuwandeln. Möchtest du auf einer sicheren Infrastruktur aufbauen, die auch flexibel austauschbar und testbar ist, solltest du deinen Weg mit der Factory gehen, da diese die meisten Best Practices übernimmt und weiterhin offen bleibt.
Der Singleton gibt dir die Möglichkeit an verschiedenen Punkten deiner Entwicklung oder deines Prozesses auf die gleiche Instanz und damit die gleichen Daten zuzugreifen. Diese Variante hat Vorteile, weil du damit die Instanz nicht durch den Prozess schleifen musst und manchmal gar nicht die Möglichkeit dazu hast, wenn diese von BADI zu BADI Implementierung gehen muss.
Grundsätzlich solltest du das Thema statische Klassen vermeiden, vor allem wenn es um das Thema Datenbehandlung und Speicherung innerhalb von Attributen geht. Statisch Attribute und Methoden können richtig eingesetzt einen Mehrwert generieren, dann aber auch nur sparsam und punktuell. Bist du dir unsicher oder weißt nicht genau, was du in deinem Fall tun sollst, dann hilft dir der Blick in den Clean ABAP Styleguide.
Komplettes Beispiel
Den kompletten Quellcode der Beispiele findest du im entsprechenden GitHub Repository von uns. Das meiste Coding wirst du in diesem Artikel finden, vor allem bei der Ausführung und Verwendung haben wir aber nur die wichtigsten Teile gezeigt.
Fazit
Glückwunsch, wenn du bis zum Ende des Artikels gekommen bist. Die verschiedenen Pattern und Methoden nebeneinander zu halten macht deshalb viel Sinn, da sie teilweise aufeinander aufbauen und sich weiterentwickeln. Jedes Pattern kann in unterschiedlichen Szenarien verwendet werden, um Mehrwerte in die Entwicklung zu bringen.
Weitere Informationen:
SAP Help - Static Classes and Singletons
SAP Help - ABAP Objects
