Verständnisfrage über Abap OO
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Hallo Leute,
ich brauch bitte ein Grundverständnis, wie das mit ABAP OO in der Praxis funktioniert.
Durch Java kenne ich mich mit der objektorientierten Programmierung aus.
Die Logik von ABAP OO ist mir mittlerweile auch klar. Also die Syntax und ähnliches.
Mein Problem ist aber:
Es gibt Funktionsbausteine, FORM und jetzt Methoden.
Wenn ich jetzt Methoden benutze möchte, muss ich dann die Funktionsbausteine durch diese ersetzen?
Oder weiterhin beides zusammen nutzen.
Als Szenario:
Ich muss einen eigens geschriebenen Funktionsbaustein in das ABAP OO Prinzip umwandeln und dabei lernen.
In den eigens geschriebenen Funktionsbaustein sind Unterprogramme. Sollte ich dann diese Unterprogramme in Methoden umwandeln.
Eine blöde Frage noch: Funktionsbausteine von der SAP selbst, kann ich doch in den Methoden ganz normal aufrufen oder?
Viele Grüße
Tekko
ich brauch bitte ein Grundverständnis, wie das mit ABAP OO in der Praxis funktioniert.
Durch Java kenne ich mich mit der objektorientierten Programmierung aus.
Die Logik von ABAP OO ist mir mittlerweile auch klar. Also die Syntax und ähnliches.
Mein Problem ist aber:
Es gibt Funktionsbausteine, FORM und jetzt Methoden.
Wenn ich jetzt Methoden benutze möchte, muss ich dann die Funktionsbausteine durch diese ersetzen?
Oder weiterhin beides zusammen nutzen.
Als Szenario:
Ich muss einen eigens geschriebenen Funktionsbaustein in das ABAP OO Prinzip umwandeln und dabei lernen.
In den eigens geschriebenen Funktionsbaustein sind Unterprogramme. Sollte ich dann diese Unterprogramme in Methoden umwandeln.
Eine blöde Frage noch: Funktionsbausteine von der SAP selbst, kann ich doch in den Methoden ganz normal aufrufen oder?
Viele Grüße
Tekko
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Moin Tekko,
eine ganz böse Vereinfachung, für die ich andere hier schon geschlachtet habe, die aber (das muss ich ja einsehen) recht eingängig ist:
Du KANNST eine statische (!) Klasse wie eine Funktionsgruppe betrachten, deren öffentliche Methoden Funktionsbaustein heißen und private Methoden Forms. Das nur zur Klärung der Begrifflichkeiten. Du solltest also die Funktionsgruppe als Ganzes betrachten, denn deren Funktionalität ist die der Klasse, die du anlegen musst.
So, und jetzt löst du dich bitte wieder von diesem Bild und denkst wieder in OO ;)
Ein Funktionsbaustein ist (im Idealfall) etwas, das eine Funktionalität kapselt und in sich autark arbeitet. Wenn du es schlecht machst, machst du es wie die SAP beim Upload/Download von Dateien vom Präsentationsserver, du kapselst einfach den Funktionsbaustein in eine Methode einer neu zu erstellenden Klasse.
Wenn du es GANZ richtig machen willst, erstellst du ein Interface mit einer Methodendefinition, die der Funktionsbausteinschnittstelle entspricht. Dahinter implementierst du eine Klasse, in der du die Methodenimplementierung codierst. Jetzt schreibst du aber nicht das Coding einfach ab, sondern versuchst den Kontext der Funktionsgruppe zu erfassen und daraus ein gescheites OO-Modell zu basteln. Leider hast du nicht gesagt, welche Funktionalität da umzusetzen ist, sonst könnte man dir bei der Modellierung auch noch helfen.
Und ja: Du kannst in Methoden einfach Funktionsbausteine aufrufen. Ich würde solche Aufrufe aber immer kapseln.
Gruß
Ralf
eine ganz böse Vereinfachung, für die ich andere hier schon geschlachtet habe, die aber (das muss ich ja einsehen) recht eingängig ist:
Du KANNST eine statische (!) Klasse wie eine Funktionsgruppe betrachten, deren öffentliche Methoden Funktionsbaustein heißen und private Methoden Forms. Das nur zur Klärung der Begrifflichkeiten. Du solltest also die Funktionsgruppe als Ganzes betrachten, denn deren Funktionalität ist die der Klasse, die du anlegen musst.
So, und jetzt löst du dich bitte wieder von diesem Bild und denkst wieder in OO ;)
Ein Funktionsbaustein ist (im Idealfall) etwas, das eine Funktionalität kapselt und in sich autark arbeitet. Wenn du es schlecht machst, machst du es wie die SAP beim Upload/Download von Dateien vom Präsentationsserver, du kapselst einfach den Funktionsbaustein in eine Methode einer neu zu erstellenden Klasse.
Wenn du es GANZ richtig machen willst, erstellst du ein Interface mit einer Methodendefinition, die der Funktionsbausteinschnittstelle entspricht. Dahinter implementierst du eine Klasse, in der du die Methodenimplementierung codierst. Jetzt schreibst du aber nicht das Coding einfach ab, sondern versuchst den Kontext der Funktionsgruppe zu erfassen und daraus ein gescheites OO-Modell zu basteln. Leider hast du nicht gesagt, welche Funktionalität da umzusetzen ist, sonst könnte man dir bei der Modellierung auch noch helfen.
Und ja: Du kannst in Methoden einfach Funktionsbausteine aufrufen. Ich würde solche Aufrufe aber immer kapseln.
Gruß
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
tekko
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo Tekko,
Ralf hat ja schon einiges gesagt. Architektonisch gesehen, muss man gegebenenfalls eine Funktionsgruppe in mehrere Klassen splitten um OO-Kriterien zu erfüllen.
Allgemein gesagt :
Methoden vs. Forms
Sauber atomarisierte Forms entsprechen weitestgehend einer Methode eines Service.
Um den Anspruch von Unitest zu erfüllen, sollte jede Datenbeschaffung gekapselt sein und deiner umgewandelten Funktionsgruppe per Dependency Injection zur Verfügung gestellt werden. Analog gilt das für alle anderen Services, die deine Hauptklasse implizit benutzt, ebenso für Customizing ( DAO und CAO Objekte ).
Ich empfehle die umzuwandelnde Funktionsgruppe zu analysieren in den Bereichen : Datenbeschaffung, Customizing, Businesslogik, allgemeine Funktionen.
Bewährt hat sich das "Matroschka-Prinzip". D.h. z.b. Du hast einen stateless Service der die Gewünschte Funktionalität macht und hierbei die Daten alle als Input-Parameter hat. Bei Bedarf, kann man um diesen einen Statefull-Service bauen, der z.b. Customizing hat ( per DI ), ggfs. Daten liest ( per DAO ).
Damit gewährleistest Du Austausch- und Erweiterbarkeit, sowie Wiederverwendbarkeit.
Und natürlich immer "Always program against an Interface".
Mal Dir ein Design des jetzigen FuBa auf und danach eines wie du es sinnvoll aufteilen würdest.
Als Hinweis : Vermeidet man Parameter im Konstruktor von Klassen ( mit Ausnahme von anderen Objekten ) und arbeitet mit Setter/Getter, kann man einen Injektor bauen. Dieser analysiert, welche Objekte er erzeugen muss um Objekt A zu bauen und macht dies. So kaskadiert er durch die Abhängigkeit und setzt das Puzzle dynamisch zu sammen. Einzig aufpassen muss man : Es darf kein Objekt verwendet werden, das wieder Objekt A braucht. Das würde zu einem Zirkelbezug führen, der nicht dynamisch auflösbar ist.
Wie Ralf gesagt hat, würde ich einen FuBa Aufruf ebenfalls in einen Statefull-Service kapseln und dann so verwenden. Idealerweise legt man sich eine eigene Basis-Exceptionklasse an, u.a. eine BAPIRET-Tabelle als Attribut hat und mit einem Getter geholt werden kann. So kann man in einem Service leicht eine klassenbasierte Exception werfen und die Rückgabe des FuBa durchschleusen und anzeigen und bewegt sich vollständig in OO.
Ralf hat ja schon einiges gesagt. Architektonisch gesehen, muss man gegebenenfalls eine Funktionsgruppe in mehrere Klassen splitten um OO-Kriterien zu erfüllen.
Allgemein gesagt :
Methoden vs. Forms
Sauber atomarisierte Forms entsprechen weitestgehend einer Methode eines Service.
Um den Anspruch von Unitest zu erfüllen, sollte jede Datenbeschaffung gekapselt sein und deiner umgewandelten Funktionsgruppe per Dependency Injection zur Verfügung gestellt werden. Analog gilt das für alle anderen Services, die deine Hauptklasse implizit benutzt, ebenso für Customizing ( DAO und CAO Objekte ).
Ich empfehle die umzuwandelnde Funktionsgruppe zu analysieren in den Bereichen : Datenbeschaffung, Customizing, Businesslogik, allgemeine Funktionen.
Bewährt hat sich das "Matroschka-Prinzip". D.h. z.b. Du hast einen stateless Service der die Gewünschte Funktionalität macht und hierbei die Daten alle als Input-Parameter hat. Bei Bedarf, kann man um diesen einen Statefull-Service bauen, der z.b. Customizing hat ( per DI ), ggfs. Daten liest ( per DAO ).
Damit gewährleistest Du Austausch- und Erweiterbarkeit, sowie Wiederverwendbarkeit.
Und natürlich immer "Always program against an Interface".
Mal Dir ein Design des jetzigen FuBa auf und danach eines wie du es sinnvoll aufteilen würdest.
Als Hinweis : Vermeidet man Parameter im Konstruktor von Klassen ( mit Ausnahme von anderen Objekten ) und arbeitet mit Setter/Getter, kann man einen Injektor bauen. Dieser analysiert, welche Objekte er erzeugen muss um Objekt A zu bauen und macht dies. So kaskadiert er durch die Abhängigkeit und setzt das Puzzle dynamisch zu sammen. Einzig aufpassen muss man : Es darf kein Objekt verwendet werden, das wieder Objekt A braucht. Das würde zu einem Zirkelbezug führen, der nicht dynamisch auflösbar ist.
Wie Ralf gesagt hat, würde ich einen FuBa Aufruf ebenfalls in einen Statefull-Service kapseln und dann so verwenden. Idealerweise legt man sich eine eigene Basis-Exceptionklasse an, u.a. eine BAPIRET-Tabelle als Attribut hat und mit einem Getter geholt werden kann. So kann man in einem Service leicht eine klassenbasierte Exception werfen und die Rückgabe des FuBa durchschleusen und anzeigen und bewegt sich vollständig in OO.
Zuletzt geändert von gtoXX am 12.04.2020 20:26, insgesamt 1-mal geändert.
"Code lügt nicht ^^"
Noch ein Ergänzung dazu:ralf.wenzel hat geschrieben: ↑10.04.2020 12:07Du KANNST eine statische (!) Klasse wie eine Funktionsgruppe betrachten, deren öffentliche Methoden Funktionsbaustein heißen und private Methoden Forms.
Die statischen Klassen würden quasi die Funktionsgruppe wiederspiegel. Wenn nun "sauber" nicht-statische Klassen (genauer Methode/Attribute) machst, dann kannst du von einer Klasse mehrere Objekte (Speicher) erzeugen - so wie in JAVA auch.
Genau das kann ein Funktionsgruppe nämlich nicht, da es die Variablen nur einmal im Speicher gibt. Und die SAP macht hier z.B. im BDT "Handstände" um ihren Speicher per Push und Pull zu retten...
---
Edit: Und noch was technisches: Eine Formroutine könnte ich mit gutem Willen auch aus einer anderen Funktionsgruppe aufrufen. Bei einer privaten Methode klappt das nicht.
Es gibt dazu übrigens auch was von Lars:
https://github.com/larshp/FORMfactor
Helps refactoring old FORM based programs to local classes with static methods.
Bin mir nicht sicher, ob das auch für Funktionsgruppen gilt. Wäre aber ein Versuch wert.
https://github.com/larshp/FORMfactor
Helps refactoring old FORM based programs to local classes with static methods.
Bin mir nicht sicher, ob das auch für Funktionsgruppen gilt. Wäre aber ein Versuch wert.
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1036
Views
Views
Email aus ABAP Verständnisfrage
von AndreFIAE2014 » 25.01.2017 14:01 • Verfasst in ABAP® für Anfänger
von AndreFIAE2014 » 25.01.2017 14:01 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
2663
Views
Views
0
Antw.
Antw.
659
Views
Views
2
Antw.
Antw.
1975
Views
Views
11
Antw.
Antw.
2686
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1156
vor 2 Tagen von DeathAndPain 4 / 1156