Wo liegt der Sinn dahinter?
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Guten Tag Liebes ABAP Forum,
Ich habe heute wieder mal ein paar Fragen mitgebracht.
Ich habe einen Quellcode geschrieben, den ich nur zum Teil verstehe. (Ja, das gibt es
)
Ich werde den Quellcode posten, und meine Anregungen/Gedanken sind mit >"< gekennzeichnet.
REPORT zmf_tutorial2.
CLASS mklasse DEFINITION. "Eine Klasse(class) wurde Definiert mit dem Namen: mklasse
PUBLIC SECTION. "Public Section definiert den öffentlichen Sichtbarkeitsbereich der Klasse (class)
DATA pdata TYPE i VALUE 3. "DATA(pdata) wird in der Klasse(class): mklasse, Deklariert.
ENDCLASS. "Klasse wird geschlossen.
DATA: eins TYPE REF TO mklasse, "eins wurde der Referenzvariable mklasse zugeordnet.
zwei LIKE REF TO eins, "zwei wurde der Referenzvariable eins zugeordnet.
drei TYPE REF TO i. "drei wurde der Referenzvariable i zugeordnet.
CREATE OBJECT eins. "eins wurde als Objekt angelegt. (Warum?)
GET REFERENCE OF eins INTO zwei. "die Referenzvariable eins wurde zwei zugewiesen?
CREATE DATA drei. "drei wurde als Objekt kreiert. (Warum?)
drei->* = zwei->*->pdata. "dereferencing in DE = zurückverfolgen, somit wurde
"drei bis zwei zurückverfolgt, und zwei bis pdata. (Warum?)
"Was ist der Sinn hinter solch einer Syntax?
Vielen Dank für eure Anregungen und Tipps im Voraus.
Mfg, D90
Ich habe heute wieder mal ein paar Fragen mitgebracht.
Ich habe einen Quellcode geschrieben, den ich nur zum Teil verstehe. (Ja, das gibt es
)Ich werde den Quellcode posten, und meine Anregungen/Gedanken sind mit >"< gekennzeichnet.
REPORT zmf_tutorial2.
CLASS mklasse DEFINITION. "Eine Klasse(class) wurde Definiert mit dem Namen: mklasse
PUBLIC SECTION. "Public Section definiert den öffentlichen Sichtbarkeitsbereich der Klasse (class)
DATA pdata TYPE i VALUE 3. "DATA(pdata) wird in der Klasse(class): mklasse, Deklariert.
ENDCLASS. "Klasse wird geschlossen.
DATA: eins TYPE REF TO mklasse, "eins wurde der Referenzvariable mklasse zugeordnet.
zwei LIKE REF TO eins, "zwei wurde der Referenzvariable eins zugeordnet.
drei TYPE REF TO i. "drei wurde der Referenzvariable i zugeordnet.
CREATE OBJECT eins. "eins wurde als Objekt angelegt. (Warum?)
GET REFERENCE OF eins INTO zwei. "die Referenzvariable eins wurde zwei zugewiesen?
CREATE DATA drei. "drei wurde als Objekt kreiert. (Warum?)
drei->* = zwei->*->pdata. "dereferencing in DE = zurückverfolgen, somit wurde
"drei bis zwei zurückverfolgt, und zwei bis pdata. (Warum?)
"Was ist der Sinn hinter solch einer Syntax?
Vielen Dank für eure Anregungen und Tipps im Voraus.
Mfg, D90
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Der Sinn dieses sinnlosen Programms liegt sinnigerweise darin, dir den Sinn oder Unsinn von Referenzvariablen an einem kurzen aber hinreichend komplexen Beispiel in den Sinn zu rufen.Django90 hat geschrieben:"Was ist der Sinn hinter solch einer Syntax?
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Hm, Du fragst nach dem Sinn eines von Dir selbst geschriebenen Programms... So, wie es da steht, hat es natürlich keinen; Du hast einfach nur irgendwelche Befehle aneinandergereiht. Kann es sein, dass Du in Wahrheit wissen möchtest, wofür man bestimmte sprachliche Elemente von ABAP OO einsetzt?
Was ich aber schon mal sagen kann, ist, dass mir bestimmte Sprachelemente von ABAP OO selber unsympathisch sind, da sie in meinen Augen hauptsächlich dazu führen, den Code unverständlich zu machen. Dazu gehört, per CREATE DATA Variablen zu generieren, die keinen Namen haben, sondern nur per Referenz angesprochen werden. Diese Referenz kann nach Belieben auf ein anderes Datenobjekt geändert werden, und wenn keine Referenz mehr auf das erste (an sich namenlose) zeigt, dann verschwindet es einfach im Nirwana (per automatisch zuschlagendem Garbage Collector). Referenzen auf Speicherbereiche gehören für mich in die Zeiten des C64 und haben in einer modernen Hochsprache nichts verloren. Das sage ich wissend, dass ich damit extrem quer zur geltenden OO-Lehrmeinung liege.
Meines Wissens wird sowas hauptsächlich dazu verwendet, Code flexibel zu machen, da Datentypen dynamisch zur Laufzeit anhand der zu verarbeitenden Daten festgelegt werden können, statt starr in einem TYPES-Befehl vorgegeben zu sein. So lassen sich wohl auch gut "Container"-Objekte bauen, die alles mögliche und unmögliche enthalten können. Aber wehe, diese Container sind nicht penibel dokumentiert (und das sind sie in der Praxis fast nie). Dann stehste da und hast kaum eine Chance zu verstehen, wo die Werte im Programm herkommen und wo sie hingehen.
Was ich aber schon mal sagen kann, ist, dass mir bestimmte Sprachelemente von ABAP OO selber unsympathisch sind, da sie in meinen Augen hauptsächlich dazu führen, den Code unverständlich zu machen. Dazu gehört, per CREATE DATA Variablen zu generieren, die keinen Namen haben, sondern nur per Referenz angesprochen werden. Diese Referenz kann nach Belieben auf ein anderes Datenobjekt geändert werden, und wenn keine Referenz mehr auf das erste (an sich namenlose) zeigt, dann verschwindet es einfach im Nirwana (per automatisch zuschlagendem Garbage Collector). Referenzen auf Speicherbereiche gehören für mich in die Zeiten des C64 und haben in einer modernen Hochsprache nichts verloren. Das sage ich wissend, dass ich damit extrem quer zur geltenden OO-Lehrmeinung liege.
Meines Wissens wird sowas hauptsächlich dazu verwendet, Code flexibel zu machen, da Datentypen dynamisch zur Laufzeit anhand der zu verarbeitenden Daten festgelegt werden können, statt starr in einem TYPES-Befehl vorgegeben zu sein. So lassen sich wohl auch gut "Container"-Objekte bauen, die alles mögliche und unmögliche enthalten können. Aber wehe, diese Container sind nicht penibel dokumentiert (und das sind sie in der Praxis fast nie). Dann stehste da und hast kaum eine Chance zu verstehen, wo die Werte im Programm herkommen und wo sie hingehen.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Daniel
Im SAP-Code bin ich mal auf eine sinnvolle Verwendung von Referenzen gestoßen. Da gabs einen FuBa dessen Übergabeparameter (sinngemäß) folgende Struktur hatte:
Auf diese Weise ist die Schnittstelle vollkommen dynamisch, sowohl hinsichtlich Datentyp, als auch hinsichtlich Anzahl der Parameter. Der offensichtlichste Nachteil liegt natürlich darin, dass der Coder sich selbst um die Konsistenz der eingehenden Daten kümmern muss. Zudem muss man bedenkten, dass zB FuBas nach ihrer Ausführung den Speicherplatz freigeben und die Referenzen auf Daten aus abgearbeiteten FuBas dann ins Leere zeigen.
Eine weitere Spielerei mit Referenzen ist, dass man damit z.B. die Input-Einschränkungen von Fubas umgehen kann. Normalerweise wird man ja noch vor dem Compilieren daran gehindert die Werte von Input-Parametern zu ändern. Ist der Input-Parameter jedoch eine Referenz, kann er dereferenziert und der Wert der referenzierten Variable geändert werden. Man ändert damit direkt Wert der (in der Aufrufhierachie weiter oben liegenden) Variable die referenziert- und deren Referenz beim Aufruf an den Fuba übergeben wurde. Eine Anwendung für dieses Szenario fällt mir jetzt jedoch nicht ein.
Als Normalsterblicher wird man aber solche Schnittstellen nicht allzuu oft brauchen.
Code: Alles auswählen.
TYPES: BEGIN OF anydata,
name TYPE string,
data TYPE REF TO data,
END OF anydata.
DATA: partab TYPE TABLE OF anydata.
Eine weitere Spielerei mit Referenzen ist, dass man damit z.B. die Input-Einschränkungen von Fubas umgehen kann. Normalerweise wird man ja noch vor dem Compilieren daran gehindert die Werte von Input-Parametern zu ändern. Ist der Input-Parameter jedoch eine Referenz, kann er dereferenziert und der Wert der referenzierten Variable geändert werden. Man ändert damit direkt Wert der (in der Aufrufhierachie weiter oben liegenden) Variable die referenziert- und deren Referenz beim Aufruf an den Fuba übergeben wurde. Eine Anwendung für dieses Szenario fällt mir jetzt jedoch nicht ein.
Als Normalsterblicher wird man aber solche Schnittstellen nicht allzuu oft brauchen.
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
280
)
»
Uiuiui, da wäre ich vorsichtig. In unserem aktuellen Projekt wäre die komplett generische Persistenzschicht ohne Referenzen nur schwerlich denkbar, auch die SAP arbeitet viel damit. Daher sollte man das schon beherrschen.
Ich habe aber auch außerhalb dieser Schicht lauter Prozesse, die für viele Objekte gleich sind (und deshalb nur einmal codiert wurden), das Coding selbst aber erst zur Laufzeit weiß, womit es überhaupt arbeitet. Beispiel: Da wir uns im Arzneimittelbereich bewegen, unterliegt unser Modul der Validierungspflicht. Wir müssen also (vereinfacht gesagt) neben einem Modul für Blutspendedienste eine komplette Simulation eines solchen Blutspendedienstes vorhalten, die alle Prozesse automatisiert testet (weil manuelle Tests im geforderten Umfang kaum zu beherrschen sind). Und die simulierten Objekte sehen natürlich anders aus als die produktiven (weil sie z. B. das Testergebnis persistent speichern müssen), das durchlaufene Coding muss aber produktive sein, weil wir das ja testen müssen.
Wichtig dabei ist eine gute Dokumentation, weil das Coding allein sich nicht mehr selbst erklärt.
Ralf
Ich habe aber auch außerhalb dieser Schicht lauter Prozesse, die für viele Objekte gleich sind (und deshalb nur einmal codiert wurden), das Coding selbst aber erst zur Laufzeit weiß, womit es überhaupt arbeitet. Beispiel: Da wir uns im Arzneimittelbereich bewegen, unterliegt unser Modul der Validierungspflicht. Wir müssen also (vereinfacht gesagt) neben einem Modul für Blutspendedienste eine komplette Simulation eines solchen Blutspendedienstes vorhalten, die alle Prozesse automatisiert testet (weil manuelle Tests im geforderten Umfang kaum zu beherrschen sind). Und die simulierten Objekte sehen natürlich anders aus als die produktiven (weil sie z. B. das Testergebnis persistent speichern müssen), das durchlaufene Coding muss aber produktive sein, weil wir das ja testen müssen.
Wichtig dabei ist eine gute Dokumentation, weil das Coding allein sich nicht mehr selbst erklärt.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Das geht auch anders, und sogar mit (noch immer funktionsfähigen) Mitteln aus längst vergangenen Releases. Und zwar kannst Du per (Programmname)Feldname auf Felder aus anderen Programmen zugreifen, insbesondere aus solchen, die in der Aufrufhierarchie weiter oben liegen. Im Funktionsbaustein kannst Du damit aus der Sandbox ausbrechen und Dir aus dem rufenden Programm Informationen beschaffen, die die Kapselung Dir eigentlich nicht rausrücken möchte. Das ist natürlich extrem schmutzig; ich hoffe, Ralf bekommt keinen Herzinfarkt, wenn er das liest.sapnup hat geschrieben:Eine weitere Spielerei mit Referenzen ist, dass man damit z.B. die Input-Einschränkungen von Fubas umgehen kann. Normalerweise wird man ja noch vor dem Compilieren daran gehindert die Werte von Input-Parametern zu ändern. Ist der Input-Parameter jedoch eine Referenz, kann er dereferenziert und der Wert der referenzierten Variable geändert werden. Man ändert damit direkt Wert der (in der Aufrufhierachie weiter oben liegenden) Variable die referenziert- und deren Referenz beim Aufruf an den Fuba übergeben wurde.
Im HCM-Umfeld kenne ich eine, jedenfalls für den lesenden Zugriff auf Werte weiter oben in der Aufrufhierarchie. Und zwar gibt es dort den User Exit ZXPADU02, der von dem Funktionsbaustein EXIT_SAPFP50M_002 gerufen wird. Dieser Exit wird im PAI des Dynpros aufgerufen, das für die Pflege von Personalstammdaten verwendet wird. Über diesen Exit hat man also die Möglichkeit, bei/nach der Pflege von Personalstammdaten noch Konsistenzprüfungen (oder was auch immer) einzubauen, bevor die Daten dann gesichert werden.sapnup hat geschrieben:Eine Anwendung für dieses Szenario fällt mir jetzt jedoch nicht ein.
Nun wird das PAI von solch Dynpro ja nicht nur beim Sichern aufgerufen, sondern auch, wenn der Benutzer nur einfach mal Enter drückt oder sonst eine Hilfsfunktion des Dynpros aufruft. Bestimmte Konsistenzabprüfungen will man aber erst durchführen, wenn der Benutzer mit den Daten zufrieden ist und sichern möchte. Also benötigt man den OK-Code des Dynpros. Der ist jedoch nicht Bestandteil des Funktionsbausteinsinterfaces, und SY-UCOMM hat sich an der Stelle als unzuverlässig erwiesen.
Da der Baustein nur für diesen User Exit da ist und demzufolge auch nirgendwo anders als von dem Programm MP000000 gerufen wird, kann man sich da behelfen, indem man schreibt:
Code: Alles auswählen.
S = '(MP000000)FCODE'.
ASSIGN (S) TO <FCODE_FROM_MP000000>. " Dieses Feldsymbol enthält jetzt den OK-Code.(Ehrlicherweise muss man dazusagen, dass die SAP inzwischen auch einen BADI anbietet, den man alternativ zu diesem UserExit nutzen kann.)
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
sapnup
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
280
)
»
Ich wäre ein schlechter Entwickler, wenn ich das nicht wüssteDeathAndPain hat geschrieben:Das ist natürlich extrem schmutzig; ich hoffe, Ralf bekommt keinen Herzinfarkt, wenn er das liest.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Oder auch Enhancements.DeathAndPain hat geschrieben:sapnup hat geschrieben:
Sehr nützlich.
(Ehrlicherweise muss man dazusagen, dass die SAP inzwischen auch einen BADI anbietet, den man alternativ zu diesem UserExit nutzen kann.)
Worin die Gefahr bei deinem nützlichen liegt, solltest Du allerdings auch erwähnen. Es können unkontrolliert Werte verändert werden und somit die ganze LUW unlogisch ergo fehlerhaft werden.
Gruß,
GTO
"Code lügt nicht ^^"
ralf.wenzel hat geschrieben:Uiuiui, da wäre ich vorsichtig. In unserem aktuellen Projekt wäre die komplett generische Persistenzschicht ohne Referenzen nur schwerlich denkbar, auch die SAP arbeitet viel damit. Daher sollte man das schon beherrschen.
Ich habe aber auch außerhalb dieser Schicht lauter Prozesse, die für viele Objekte gleich sind (und deshalb nur einmal codiert wurden), das Coding selbst aber erst zur Laufzeit weiß, womit es überhaupt arbeitet. Beispiel: Da wir uns im Arzneimittelbereich bewegen, unterliegt unser Modul der Validierungspflicht. Wir müssen also (vereinfacht gesagt) neben einem Modul für Blutspendedienste eine komplette Simulation eines solchen Blutspendedienstes vorhalten, die alle Prozesse automatisiert testet (weil manuelle Tests im geforderten Umfang kaum zu beherrschen sind). Und die simulierten Objekte sehen natürlich anders aus als die produktiven (weil sie z. B. das Testergebnis persistent speichern müssen), das durchlaufene Coding muss aber produktive sein, weil wir das ja testen müssen.
Wichtig dabei ist eine gute Dokumentation, weil das Coding allein sich nicht mehr selbst erklärt.
Ralf
Hallo Ralf,
Da würde ich eher auf ein Konzept mit Dependency Injection, Interfaces und Mocks verweisen. Dann muss nichts separat dokumentiert werden und Generik ist nicht zwingend notwendig. Es klingt für mich so, als codiert ihr gegen Klassen und nicht gegen Interfaces.
VG,
GTO
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
280
)
»
Nein, tun wir nicht. Ich habe festgestellt, dass die wenigsten etwas mit Worten wie "Mock" anfangen könnengtoXX hat geschrieben:Da würde ich eher auf ein Konzept mit Dependency Injection, Interfaces und Mocks verweisen. Dann muss nichts separat dokumentiert werden und Generik ist nicht zwingend notwendig. Es klingt für mich so, als codiert ihr gegen Klassen und nicht gegen Interfaces.
In der Tat mocken wir, was wir für die Simulation nicht brauchen. Und wenn wir gegen Klassen programmieren würden, könnten wir die kaum austauschen - das geht nur, weil wir gegen Interfaces programmieren.Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
1707
Views
Views
Ermitteln, ob Buchungsdatum in einer geschlossenen Buchungsperiode liegt
von SweetRuedi » 29.05.2020 12:22 • Verfasst in ABAP® Core
von SweetRuedi » 29.05.2020 12:22 • Verfasst in ABAP® Core
1
Antw.
Antw.
1880
Views
Views
Sinn und Unsinn von Datenreferenzvariablen
von ralf.wenzel » 14.03.2014 19:05 • Verfasst in ABAP Objects®
von ralf.wenzel » 14.03.2014 19:05 • Verfasst in ABAP Objects®
9
Antw.
Antw.
2108
Views
Views
2
Antw.
Antw.
1320
Views
Views
8
Antw.
Antw.
2801
Views
Views
Sinn und Unsinn von Alternativeditoren für ABAP
von ralf.wenzel » 27.04.2006 11:56 • Verfasst in SAP - Allgemeines
von ralf.wenzel » 27.04.2006 11:56 • Verfasst in SAP - Allgemeines
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 6 Stunden von ralf.wenzel 104 / 10022
vor 6 Stunden von ralf.wenzel 104 / 10022
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 6 Stunden von ralf.wenzel 104 / 10022
vor 6 Stunden von ralf.wenzel 104 / 10022