Exporting-Parameter wird nicht initialisiert?!?
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Hallo zusammen,
ich falle gerade aus allen Wolken und wollte fragen, ob ich etwas grundsätzlich falsch verstanden habe oder nur irgendein Detail übersehe.
Ich bin immer davon ausgegangen, dass wenn eine (programmlokale, in meinem Fall auch statische) Methode über einen EXPORTING-Parameter verfügt, dieser bei jedem Methodenaufruf automatisch neu initialisiert wird, ähnlich wie wenn ich ihn in der Methode mit DATA neu definieren würde.
Nun habe ich aber folgende Methode:
Diese Methode wird in einem LOOP vom aufrufenden Code wiederholt gerufen. Jetzt habe ich mich gewundert, weshalb BASE_SALARY gigantische Proportionen annimmt und habe im Debugger festgestellt, dass er bei jedem Aufruf mit dem BASE_SALARY des vorigen Durchgangs weitermacht. Haben EXPORTING-Parameter den Charakter von STATICS-Variablen? Oder mache ich irgendwo einen Denkfehler?
ich falle gerade aus allen Wolken und wollte fragen, ob ich etwas grundsätzlich falsch verstanden habe oder nur irgendein Detail übersehe.
Ich bin immer davon ausgegangen, dass wenn eine (programmlokale, in meinem Fall auch statische) Methode über einen EXPORTING-Parameter verfügt, dieser bei jedem Methodenaufruf automatisch neu initialisiert wird, ähnlich wie wenn ich ihn in der Methode mit DATA neu definieren würde.
Nun habe ich aber folgende Methode:
Code: Alles auswählen.
CLASS W DEFINITION ABSTRACT FINAL.
PUBLIC SECTION.
CLASS-METHODS COMPUTE_BASE_SALARY_FROM_IT8 IMPORTING IT8_DATA TYPE LINE_OF_BUFFER_0008
ONLY_RESPECT_THESE_WAGE_TYPES TYPE LGART_TAB OPTIONAL
EXPORTING BASE_SALARY TYPE PAD_AMT7S
WAGE_TYPE_WITH_HIGHEST_AMOUNT TYPE LGART.
ENDCLASS.
Und dazu die Implementierung:
METHOD COMPUTE_BASE_SALARY_FROM_IT8.
DATA: LOCAL_COPY_OF_IT8_DATA TYPE LINE_OF_BUFFER_0008,
LGA TYPE PA0008-LGA01,
BET TYPE PA0008-BET01,
OPK TYPE PA0008-OPK01,
HIGHEST_AMOUNT TYPE PA0008-BET01.
LOCAL_COPY_OF_IT8_DATA = IT8_DATA. " syntaktisch leider notwendig, um VARYING verwenden zu können
DO 5 TIMES VARYING LGA FROM LOCAL_COPY_OF_IT8_DATA-LGA01 NEXT LOCAL_COPY_OF_IT8_DATA-LGA02
VARYING BET FROM LOCAL_COPY_OF_IT8_DATA-BET01 NEXT LOCAL_COPY_OF_IT8_DATA-BET02
VARYING OPK FROM LOCAL_COPY_OF_IT8_DATA-OPK01 NEXT LOCAL_COPY_OF_IT8_DATA-OPK02.
CHECK LGA IS NOT INITIAL.
IF ONLY_RESPECT_THESE_WAGE_TYPES[] IS NOT INITIAL.
CHECK LINE_EXISTS( ONLY_RESPECT_THESE_WAGE_TYPES[ TABLE_LINE = LGA ] ).
ENDIF.
IF BET > HIGHEST_AMOUNT.
WAGE_TYPE_WITH_HIGHEST_AMOUNT = LGA.
HIGHEST_AMOUNT = BET.
ENDIF.
BASE_SALARY = SWITCH #( OPK WHEN SPACE THEN BASE_SALARY + BET
ELSE BASE_SALARY - BET ).
ENDDO.
ENDMETHOD.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von PeterPaletti (Specialist / 336 / 29 /
96
)
»
Wirkung
Aus der SAP Doku zu Parametern von Methoden.
Definition von Formalparametern p1 p2 ... für Methoden.
Mit VALUE oder REFERENCE wird festgelegt, ob ein Parameter p1 p2 ... per Wert oder per Referenz übergeben wird. Wenn nur ein Name p1 p2 ... angegeben wird, wird der Parameter standardmäßig per Referenz übergeben.
Und weiter:
Ein Ausgabeparameter, der für Referenzübergabe definiert ist, verhält sich wie ein Ein-/Ausgabeparameter, d.h. er wird bei Aufruf der Methode nicht initialisiert. Deshalb sollte vor dem ersten Schreibzugriff kein Lesezugriff auf ihn erfolgen. Weiterhin ist Vorsicht geboten, wenn Inhalt an solche Parameter hinzugefügt wird, wie z.B. beim Einfügen von Zeilen in interne Tabellen.
Hilft das?
Aus der SAP Doku zu Parametern von Methoden.
Definition von Formalparametern p1 p2 ... für Methoden.
Mit VALUE oder REFERENCE wird festgelegt, ob ein Parameter p1 p2 ... per Wert oder per Referenz übergeben wird. Wenn nur ein Name p1 p2 ... angegeben wird, wird der Parameter standardmäßig per Referenz übergeben.
Und weiter:
Ein Ausgabeparameter, der für Referenzübergabe definiert ist, verhält sich wie ein Ein-/Ausgabeparameter, d.h. er wird bei Aufruf der Methode nicht initialisiert. Deshalb sollte vor dem ersten Schreibzugriff kein Lesezugriff auf ihn erfolgen. Weiterhin ist Vorsicht geboten, wenn Inhalt an solche Parameter hinzugefügt wird, wie z.B. beim Einfügen von Zeilen in interne Tabellen.
Hilft das?
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Ja, vielen Dank. Der Wert kommt demnach also vom Aufrufer runter. Finde ich aber schwach von der SAP. Mit den Methoden sind sie angetreten, die Schwächen der Formroutinen zu beheben, darunter insbesondere die änderbaren USING-Parameter, und dann implementieren sie EXPORTING-Parameter so, dass sie sich technisch wie CHANGING-Parameter verhalten, machen also genau den gleichen Schwachsinn erneut in grün.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Jein. Nur wenn du den Parameter per Referenz übergibst. Per Value wird der Parameter sehr wohl neu "initialisiert".
Macht in gewisser Hinsicht durchaus Sinn. Wenn man die "Kosten" für die Kopie einer großen Tabelle im Speicher bedenkt ist es sinnvoller nach Möglicheit mit dem "Original" zu arbeiten. Diverse Perfomancetests und Codeprüfungen meckern ja auch, wenn man einen per Value definierten Parameter hat, der eine "breite" Tabelle als Typ verwendet.
Dabei haben Sie dann nur eben auch das Verhalten für alle Parameterarten gleichgezogen. Mach ich unterschiedliche Parameterarten, die sich dann im Kernel auch anders verhalten oder mach ich doch alle gleich und füge nur ein bisschen Beiwerk an (IMPORTINGs haben ein READ-ONLY Flag im Debugger) um die Komplexität nicht zu sehr zu erhöhen?
Irgendwie ist es wie mit der Wahl zwischen Pest und Cholera.
Macht in gewisser Hinsicht durchaus Sinn. Wenn man die "Kosten" für die Kopie einer großen Tabelle im Speicher bedenkt ist es sinnvoller nach Möglicheit mit dem "Original" zu arbeiten. Diverse Perfomancetests und Codeprüfungen meckern ja auch, wenn man einen per Value definierten Parameter hat, der eine "breite" Tabelle als Typ verwendet.
Dabei haben Sie dann nur eben auch das Verhalten für alle Parameterarten gleichgezogen. Mach ich unterschiedliche Parameterarten, die sich dann im Kernel auch anders verhalten oder mach ich doch alle gleich und füge nur ein bisschen Beiwerk an (IMPORTINGs haben ein READ-ONLY Flag im Debugger) um die Komplexität nicht zu sehr zu erhöhen?
Irgendwie ist es wie mit der Wahl zwischen Pest und Cholera.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Das mit der Referenz habe ich schon verstanden und sehe auch den Sinn. Aber dennoch müsste trotzdem ein impliziter CLEAR durch den EXPORTING-Parameter verursacht werden. Der kostet nicht nennenswert Rechenzeit; da ist das ganze OO-Geraffel viel laufzeitintensiver (und die SAP leistet sich das trotzdem, weil gut strukturierter Code heutzutage mehr wert ist als schneller (auch wenn ich meine eigene Meinung zu der Frage habe, ob ABAP OO zu besser strukturiertem Code geführt hat)).
EXPORTING mit Referenz und impliziter CLEAR als Unterschied zu CHANGING, das wäre hier in meinen Augen der offensichtliche Königsweg und auch das, was man von der Logik her erwartet hätte.
EXPORTING mit Referenz und impliziter CLEAR als Unterschied zu CHANGING, das wäre hier in meinen Augen der offensichtliche Königsweg und auch das, was man von der Logik her erwartet hätte.
Beitrag
von a-dead-trousers (Top Expert / 4287 / 214 /
1142
)
»
Das würde aber den Parameter SOFORT und nur durch den Aufruf der Methode zurücksetzen. Auch wenn z.B. eine Exception ausgelöst wird und eigentlich keine sonstige Verarbeitung passiert ist. So hat man zumindest als Programmierer noch eine Wahl individuell zu reagieren.
Ich sage jetzt nicht, dass das eine gute Lösung ist, nur dass das vermutlich die Intention hinter dem Verhalten war und es so implementiert wurde.
Im Grund hat man z.B. in C/C++ ja auch kein automatisches Löschen von Parametern, die in der Schnittstelle einer Funktion als Zeiger (um einen EXPORTING ähnlichen Parameter zu simulieren) übergeben werden.
Ich sage jetzt nicht, dass das eine gute Lösung ist, nur dass das vermutlich die Intention hinter dem Verhalten war und es so implementiert wurde.
Im Grund hat man z.B. in C/C++ ja auch kein automatisches Löschen von Parametern, die in der Schnittstelle einer Funktion als Zeiger (um einen EXPORTING ähnlichen Parameter zu simulieren) übergeben werden.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Die Kosten für die Kopie einer grossen Tabelle sind in SAP zu vernachlässigen.a-dead-trousers hat geschrieben: ↑03.05.2023 18:19Macht in gewisser Hinsicht durchaus Sinn. Wenn man die "Kosten" für die Kopie einer großen Tabelle im Speicher bedenkt ist es sinnvoller nach Möglicheit mit dem "Original" zu arbeiten.
https://help.sap.com/doc/abapdocu_751_i ... tion_3.htm
Laut 947096 gibt es table sharing bereits seit Release 610.
Ich verwende daher immer returning und nicht exporting.
Im ersten Moment dachte ich, das steht doch explizit in der Doku. Hab mich falsch erinnert, es steht im Styleguide :)
https://github.com/SAP/styleguides/blob ... parameters
Davon abgesehen, würde ich aber auch RETURNING bevorzugen und habe praktisch keine Anwendungsfälle mehr für EXPORTING:
https://github.com/SAP/styleguides/blob ... -exporting
https://github.com/SAP/styleguides/blob ... parameters
Davon abgesehen, würde ich aber auch RETURNING bevorzugen und habe praktisch keine Anwendungsfälle mehr für EXPORTING:
https://github.com/SAP/styleguides/blob ... -exporting
Beitrag
von DeathAndPain (Top Expert / 1806 / 214 /
396
)
»
Das finde ich auch richtig so, wenn ich eine Methode aufrufe und davon einen EXPORTING-Parameter zurückbekomme, dass dieser im Falle einer Exception initial ist. Es ist eben kein CHANGING-Parameter; er sollte auf keinen Fall einen "alten" Wert enthalten.a-dead-trousers hat geschrieben: ↑03.05.2023 21:31Das würde aber den Parameter SOFORT und nur durch den Aufruf der Methode zurücksetzen. Auch wenn z.B. eine Exception ausgelöst wird und eigentlich keine sonstige Verarbeitung passiert ist.
Wie soll diese Wahl aussehen? Dass man angesichts der Exception gerne den Wert retten möchte, den man vorher in dem Feld hatte, das man (aus Aufrufersicht) als IMPORTING-Zielfeld angegeben hat? In meinen Augen ergibt das nicht den Hauch eines Sinnes. Wenn ich eine Methode rufe und ein Feld angebe, in das mir der Rückgabewert gestellt werden soll, dann sollte ich unter keinen Umständen ein Interesse daran haben, den Wert zu behalten, der vorher in diesem Feld gestanden hat.So hat man zumindest als Programmierer noch eine Wahl individuell zu reagieren.
Davon konnte ich in dem Link nichts lesen.rob_abc hat geschrieben: ↑04.05.2023 07:28Die Kosten für die Kopie einer grossen Tabelle sind in SAP zu vernachlässigen.
https://help.sap.com/doc/abapdocu_751_i ... tion_3.htm
Ich normalerweise auch. Aber wenn die Methode mehr als einen Wert zurückliefern soll, funktioniert das nicht. Es sei denn, Du willst Dir aufwendig einen Rückgabewertstrukturtyp definieren, der aus den Feldern besteht, die Du sonst per EXPORTING zurückliefern würdest. Das finde ich aber übertrieben, und es bringt in meinen Augen auch keine nennenswerten Vorteile. Im Gegenteil: Wenn Du im aufrufenden Programm die Werte in unterschiedlichen Feldern brauchst (was häufig der Fall ist), dann musst Du nach dem Methodenaufruf die Bestandteile der RETURNING-Struktur aufwendig in die Felder umkopieren, in denen Du sie in Wahrheit haben möchtest. Es macht auch das Programm eher schlechter als besser lesbar, wenn Du solch einen Pseudotyp als Wasserkopf einführst, anstatt in der IMPORTING-Klausel des Aufrufers die Rückgabewerte gut nachlesbar in die Felder zu verteilen, in denen Du sie tatsächlich haben möchtest.
Ja, aber das ist doch eine Krücke, dass ABAP nicht von sich aus "reliable" Werte im Exporting-Parameter liefert. Und "reliable" heißt für mich bei einem in der Methode als "EXPORTING" deklarierten Parameter, dass genau das drinsteht, was die Methode reinfüllt und demnach auch nichts drinsteht, wenn sie nichts reinfüllt.fr-g hat geschrieben:Im ersten Moment dachte ich, das steht doch explizit in der Doku. Hab mich falsch erinnert, es steht im Styleguide :)
https://github.com/SAP/styleguides/blob ... parameters
Nur weil deine Erwartung eine andere ist, ist sie deswegen nicht richtig. Zumal dein Performance-Argument absolut falsch ist. OO ist in keinem Stück Laufzeit intensiver.DeathAndPain hat geschrieben: ↑03.05.2023 19:53Das mit der Referenz habe ich schon verstanden und sehe auch den Sinn. Aber dennoch müsste trotzdem ein impliziter CLEAR durch den EXPORTING-Parameter verursacht werden. Der kostet nicht nennenswert Rechenzeit; da ist das ganze OO-Geraffel viel laufzeitintensiver (und die SAP leistet sich das trotzdem, weil gut strukturierter Code heutzutage mehr wert ist als schneller (auch wenn ich meine eigene Meinung zu der Frage habe, ob ABAP OO zu besser strukturiertem Code geführt hat)).
EXPORTING mit Referenz und impliziter CLEAR als Unterschied zu CHANGING, das wäre hier in meinen Augen der offensichtliche Königsweg und auch das, was man von der Logik her erwartet hätte.
OO hat nur da nicht zu strukturierterem Code geführt weil die meisten die ABAP programmieren überhaupt keine Ahnung von Programmierung haben. Ich hab genug Leute mit >25 Jahren erfahrung gesehen die nur eines können : User-exits bedienen. Von Software-Architektur 0 Ahnung. Von OO , egal welchem 0 Ahnung. SAP größter Fehler war es überhaupt den alten Schrott lauffähig zu halten. Denn diese Leute können nicht mal saubere prozedurale Programmierung.
EXPORTING ist vor allem einer Sache geschuldet : Ich muss es nicht abfragen, wenn ich es nicht will. CHANGING aber ist Pflicht, wenn es nicht optional deklariert wurde. Ergo hast Du die Logik noch nicht ganz verstanden ^^
"Code lügt nicht ^^"
Das ist grundsätzlich dennoch falsch und wirkt sich nicht bei 1-mal Operationen aus. Wenn du mal Anwendungen im Massenbereich schreibst, merkst du das sehr wohl.rob_abc hat geschrieben: ↑04.05.2023 07:28Die Kosten für die Kopie einer grossen Tabelle sind in SAP zu vernachlässigen.a-dead-trousers hat geschrieben: ↑03.05.2023 18:19Macht in gewisser Hinsicht durchaus Sinn. Wenn man die "Kosten" für die Kopie einer großen Tabelle im Speicher bedenkt ist es sinnvoller nach Möglicheit mit dem "Original" zu arbeiten.
https://help.sap.com/doc/abapdocu_751_i ... tion_3.htm
Laut 947096 gibt es table sharing bereits seit Release 610.
Ich verwende daher immer returning und nicht exporting.
Mal abgesehen davon, das Du selbst Gigabyte und Terrabyte Arbeitsspeicher volllaufen lassen kannst.
"Code lügt nicht ^^"
Beim klassischen Report nicht. Bei wirklichen Massendaten schon. Returning sollte daher dennoch immer nur verwendet werden, wenn das Ergebnis dem klassischen VAT entspricht. Validierung, Anreicherung, Transformation. Es ist wie bei Microsoft. Anstatt anständig zu programmieren, nötig man dem Anwender den Kauf von leistungsfähigerer Hardware auf :)fr-g hat geschrieben: ↑04.05.2023 08:08Im ersten Moment dachte ich, das steht doch explizit in der Doku. Hab mich falsch erinnert, es steht im Styleguide :)
https://github.com/SAP/styleguides/blob ... parameters
Davon abgesehen, würde ich aber auch RETURNING bevorzugen und habe praktisch keine Anwendungsfälle mehr für EXPORTING:
https://github.com/SAP/styleguides/blob ... -exporting
Zuletzt geändert von gtoXX am 08.05.2023 23:13, insgesamt 1-mal geändert.
"Code lügt nicht ^^"
Nun aus deiner Sicht gibt es keinen Sinn. Weil Du bei Exceptions die Resumable Option vergisst, auch wenn diese seltener genutzt wird. Es macht absolut Sinn das der alte Wert exakt so bleibt. Ich führe eine Option mit Fehler aus, catche den Fehler und setze die Ausführung fort. Das würde keinen Sinn machen, wenn mein Wert auf einmal weg wäre. RETURNING Parameter werden in diesem Szenario logischerweise in jedem Fall gecleart.DeathAndPain hat geschrieben: ↑08.05.2023 21:32Das finde ich auch richtig so, wenn ich eine Methode aufrufe und davon einen EXPORTING-Parameter zurückbekomme, dass dieser im Falle einer Exception initial ist. Es ist eben kein CHANGING-Parameter; er sollte auf keinen Fall einen "alten" Wert enthalten.a-dead-trousers hat geschrieben: ↑03.05.2023 21:31Das würde aber den Parameter SOFORT und nur durch den Aufruf der Methode zurücksetzen. Auch wenn z.B. eine Exception ausgelöst wird und eigentlich keine sonstige Verarbeitung passiert ist.
Wie soll diese Wahl aussehen? Dass man angesichts der Exception gerne den Wert retten möchte, den man vorher in dem Feld hatte, das man (aus Aufrufersicht) als IMPORTING-Zielfeld angegeben hat? In meinen Augen ergibt das nicht den Hauch eines Sinnes. Wenn ich eine Methode rufe und ein Feld angebe, in das mir der Rückgabewert gestellt werden soll, dann sollte ich unter keinen Umständen ein Interesse daran haben, den Wert zu behalten, der vorher in diesem Feld gestanden hat.So hat man zumindest als Programmierer noch eine Wahl individuell zu reagieren.
Davon konnte ich in dem Link nichts lesen.rob_abc hat geschrieben: ↑04.05.2023 07:28Die Kosten für die Kopie einer grossen Tabelle sind in SAP zu vernachlässigen.
https://help.sap.com/doc/abapdocu_751_i ... tion_3.htm
Ich normalerweise auch. Aber wenn die Methode mehr als einen Wert zurückliefern soll, funktioniert das nicht. Es sei denn, Du willst Dir aufwendig einen Rückgabewertstrukturtyp definieren, der aus den Feldern besteht, die Du sonst per EXPORTING zurückliefern würdest. Das finde ich aber übertrieben, und es bringt in meinen Augen auch keine nennenswerten Vorteile. Im Gegenteil: Wenn Du im aufrufenden Programm die Werte in unterschiedlichen Feldern brauchst (was häufig der Fall ist), dann musst Du nach dem Methodenaufruf die Bestandteile der RETURNING-Struktur aufwendig in die Felder umkopieren, in denen Du sie in Wahrheit haben möchtest. Es macht auch das Programm eher schlechter als besser lesbar, wenn Du solch einen Pseudotyp als Wasserkopf einführst, anstatt in der IMPORTING-Klausel des Aufrufers die Rückgabewerte gut nachlesbar in die Felder zu verteilen, in denen Du sie tatsächlich haben möchtest.
Ja, aber das ist doch eine Krücke, dass ABAP nicht von sich aus "reliable" Werte im Exporting-Parameter liefert. Und "reliable" heißt für mich bei einem in der Methode als "EXPORTING" deklarierten Parameter, dass genau das drinsteht, was die Methode reinfüllt und demnach auch nichts drinsteht, wenn sie nichts reinfüllt.fr-g hat geschrieben:Im ersten Moment dachte ich, das steht doch explizit in der Doku. Hab mich falsch erinnert, es steht im Styleguide :)
https://github.com/SAP/styleguides/blob ... parameters
Es ist keine Krücke oder sonst was, sondern tatsächliche absolute Programmierlogik. Das ist nicht nur bei SAP so.
Und man kann sich das auch sehr gut zu Nutze machen. Z.b. wenn man mehrere Zeilen einer Tabelle validiert. Ich schreibe einen Service der Inhalte validiert. z.b. bei einer Schnittstelle. Mein Service löst immer einen Fehler aus, wenn eines der Felder nicht passt. So kann ich ganz leicht ermitteln welche validen Werte übrig bleiben.
Ich schreibe mir vor dem Catch die fehlerfreien Werten per INSERT in eine Tabelle TAB_FEHLERFREI oder lösche einfach die Zeile aus meiner internen Tabelle im Catch. Trotz EXCEPTION bleibt mir der Inhalt erhalten, weil die Exception resumable ist. Danach verarbeite ich die Fehlerfreien Sätze, informiere den Anwender über die Fehlerhaften. Mit minimalem Coding-Aufwand.
Wo ist das Unsinn ?
Zuletzt geändert von gtoXX am 08.05.2023 23:50, insgesamt 2-mal geändert.
"Code lügt nicht ^^"
DeathAndPain hat geschrieben: ↑08.05.2023 21:32Sorry, aber was ist das noch für ein Unsinn ? Von CORRESPONDING #( ... mapping b = c ) hast Du anscheinend noch nichts gehört.a-dead-trousers hat geschrieben: ↑03.05.2023 21:31Ich normalerweise auch. Aber wenn die Methode mehr als einen Wert zurückliefern soll, funktioniert das nicht. Es sei denn, Du willst Dir aufwendig einen Rückgabewertstrukturtyp definieren, der aus den Feldern besteht, die Du sonst per EXPORTING zurückliefern würdest. Das finde ich aber übertrieben, und es bringt in meinen Augen auch keine nennenswerten Vorteile. Im Gegenteil: Wenn Du im aufrufenden Programm die Werte in unterschiedlichen Feldern brauchst (was häufig der Fall ist), dann musst Du nach dem Methodenaufruf die Bestandteile der RETURNING-Struktur aufwendig in die Felder umkopieren, in denen Du sie in Wahrheit haben möchtest. Es macht auch das Programm eher schlechter als besser lesbar, wenn Du solch einen Pseudotyp als Wasserkopf einführst, anstatt in der IMPORTING-Klausel des Aufrufers die Rückgabewerte gut nachlesbar in die Felder zu verteilen, in denen Du sie tatsächlich haben möchtest.
Wenn tatsächlich mal gemappt werden muss, ist das für den Programmierer sogar klar ersichtlich. SAP hat in manchen Tabellen so einen Fehler im Datenhaushalt. Z.b. heisst es mal IDOCTP und mal IDOCTYP. Aber wenigstens kann man das jetzt in einer Codezeile lösen. Wer noch 7.31 einsetzt hält nichts von Effizienz.
In eine Importing Klausel gehört nicht was für die Rückgabe relevant ist. Es gehört da nur rein was für die Ausführung der Methode tatsächlich nötig ist, wenn man SoC folgt muss man für viele Fubas von SAP mehrere Methoden schreiben. Denn FuBas verstossen gegen das Cleancode Prinzip und gegen OO. Die Rückgabe einer Methode kann dagegen naturgemäß völlig beliebig sein.
"Code lügt nicht ^^"
Ich kenne euch ja nun teilweise über die Jahre als fähige Antworter. SAP hat sich bei der Einführung von OO stark an Java orientiert. So ziemlich alles ist 1:1 Java. Nur die unsägliche Multi-Vererbung hat man gleich weg gelassen.
Nicht in allem hat man OO befolgt oder hielt die programmierenden Verwender vielleicht für zu dumm. ALV Grid ist so ein Klassiker. Wesentliche Dinge wurden als private versteckt, die gar nicht private sein dürften. Noch dazu gibt es von manchem X-Versionen, was weder DRY entspricht noch mit dem Prinzip "Composition over Inheritance" erklärt werden kann. Ist wie MM und SD bei SAP .. 2 machen das Gleiche, aber reden nicht miteinander.
Trotzdem sage ich, nachdem was ich gelese habe : Bitte etwa mehr über den Tellerand schauen.
Nicht in allem hat man OO befolgt oder hielt die programmierenden Verwender vielleicht für zu dumm. ALV Grid ist so ein Klassiker. Wesentliche Dinge wurden als private versteckt, die gar nicht private sein dürften. Noch dazu gibt es von manchem X-Versionen, was weder DRY entspricht noch mit dem Prinzip "Composition over Inheritance" erklärt werden kann. Ist wie MM und SD bei SAP .. 2 machen das Gleiche, aber reden nicht miteinander.
Trotzdem sage ich, nachdem was ich gelese habe : Bitte etwa mehr über den Tellerand schauen.
"Code lügt nicht ^^"
Vergleichbare Themen
3
Antw.
Antw.
4379
Views
Views
Funktionsbaustein interne Tabelle als Exporting Parameter
von sgoedde » 27.10.2008 12:53 • Verfasst in ABAP® für Anfänger
von sgoedde » 27.10.2008 12:53 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
683
Views
Views
SAP Ausnahmeklasse - &OPERATION& im exporting parameter nicht befüllbar
von PlacidHysteria » 09.06.2021 11:47 • Verfasst in ABAP Objects®
von PlacidHysteria » 09.06.2021 11:47 • Verfasst in ABAP Objects®
3
Antw.
Antw.
2215
Views
Views
0
Antw.
Antw.
1163
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.