Dynamischer Methodenaufruf (Teil 327)

Die Frage ist als "gel├Âst" markiert. Den entsprechend Beitrag findest du hier.

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
12 Beitr├Ąge • Seite 1 von 1
12 Beitr├Ąge Seite 1 von 1

Dynamischer Methodenaufruf (Teil 327)

Beitrag von Icke0801 (Specialist / 126 / 97 / 7 ) »
Hallo zusammen,

Ich habe hier etliche Methoden in verschiedenen, die den gleichen Aufbau haben. Das kann man ja sicherlich verk├╝rzen, und wir sind ja faul ­čśŐ

Code: Alles ausw├Ąhlen.

  DATA(object_ref) = cl_abap_typedescr=>describe_by_object_ref( lo_object ).
  DATA(class_desc) = CAST cl_abap_classdescr( object_ref ).
  READ TABLE class_desc->methods ASSIGNING FIELD-SYMBOL(<method>)
                                 WITH KEY name = 'GET_MACHWAS'.
  IF sy-subrc = 0.
    CALL METHOD lo_object->(<method>-name)
      RECEIVING
        result = result.
  ELSE.
    BREAK-POINT.
  ENDIF.
Dazu habe ich folgende Fragen:
  • wie komme ich an den Typen des Returning-Parameters (Inline Deklaration funktioniert hier nicht)
  • Warum kann ich nicht auf die Interface Methoden ('ZIF_INTERFACE~GET_MACHWAS') zugreifen?
    Der Read Table geht nur mit 'GET_MACHWAS'
Hat da jemand ein paar Tipps f├╝r mich?
--
Gr├╝├če aus der Endlosschleife
-= Icke =-
abapTools

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei f├╝r Ausbildungsberufe und Werksstudenten


Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von a-dead-trousers (Top Expert / 4286 / 214 / 1142 ) »
Genau hierf├╝r gibt es die Interfaces.

Code: Alles ausw├Ąhlen.

case type of lo_object.
  when type ZIF_INTERFACE into data(lr_interface).
    result = lr_interface->get_machwas( ).
  when others.
    BREAK-POINT.
endcase.
Sofern du deine Methoden damit verwaltest, kannst du beliebige Objekte verwenden und hast dennoch immer Zugriff darauf ohne auf RTTI oder andere dynamische Ans├Ątze zur├╝ckzugreifen.

Der Ansatz mit CASE TYPE OF gef├Ąllt mir insofern am besten, als man damit in der 7.50er Syntax gleich mit Inline-Deklarationen eine Variable erzeugen kann und man muss sich nicht um die m├Âgliche Exception bei einem gew├Âhnlichen Casting ( ?= ) k├╝mmern. Au├čerdem pr├╝ft das Konstrukt auch ob lo_object ├╝berhaupt existiert und somit f├Ąllt auch ein zus├Ątzliches IF ... IS BOUND bzw. IF ... IS NOT INITIAL weg.

EDIT:
Was den Typen des Returning-Parameters angeht, kannst du diesen ja entweder im Interface oder im DDIC definieren und kannst somit global darauf zugreifen.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers f├╝r den Beitrag:
Icke0801

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

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von Icke0801 (Specialist / 126 / 97 / 7 ) »
a-dead-trousers hat geschrieben: ÔćĹ
30.04.2022 10:28

Sofern du deine Methoden damit verwaltest, kannst du beliebige Objekte verwenden und hast dennoch immer Zugriff darauf ohne auf RTTI oder andere dynamische Ans├Ątze zur├╝ckzugreifen.

Der Ansatz mit CASE TYPE OF gef├Ąllt mir insofern am besten, als man damit in der 7.50er Syntax gleich mit Inline-Deklarationen eine Variable erzeugen kann und man muss sich nicht um die m├Âgliche Exception bei einem gew├Âhnlichen Casting ( ?= ) k├╝mmern. Au├čerdem pr├╝ft das Konstrukt auch ob lo_object ├╝berhaupt existiert und somit f├Ąllt auch ein zus├Ątzliches IF ... IS BOUND bzw. IF ... IS NOT INITIAL weg.
Die Klassen haben ├╝ber 20 Interfaces. Deswegen bin ich diesen Weg gegangen. Die Methoden unterscheiden sich vom Namen und den Typen des Returning Parameters.
a-dead-trousers hat geschrieben: ÔćĹ
30.04.2022 10:28
EDIT:
Was den Typen des Returning-Parameters angeht, kannst du diesen ja entweder im Interface oder im DDIC definieren und kannst somit global darauf zugreifen.
Ich muss ja herausfinden, welcher Type gerade am Wickel ist. Im DDIC sind die nat├╝rlich hinterlegt. ├ťber cl_abap_classdescr bekomme ich diese Info aber leider nicht.
--
Gr├╝├če aus der Endlosschleife
-= Icke =-
abapTools

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von a-dead-trousers (Top Expert / 4286 / 214 / 1142 ) »
Icke0801 hat geschrieben: ÔćĹ
30.04.2022 12:15
Die Klassen haben ├╝ber 20 Interfaces. Deswegen bin ich diesen Weg gegangen. Die Methoden unterscheiden sich vom Namen und den Typen des Returning Parameters.
Das ist dann eh perfekt f├╝r CASE TYPE OF.
Je nachdem welches Interface das Objekt implementiert hat, kannst du den statischen Methodenaufruf damit realisieren.

Implementieren eigentlich alle Klassen die ganzen 20 Interfaces oder kannst du die Objekte irgendwie "gruppieren"? Sprich alle mit Interface A haben kein Interface B usw.
Wenn zweiteres, dann musst du dir eigentlich nur ├╝berlegen wie du effizient die Methodenaufrufe zusammenfassen kannst um m├Âglichst kleine CASE TYPE OF-Konstrukte zu haben.

z.B. Zwei Interfaces haben die Methode GET_NAME aber mit unterschiedliche Parametern. Du willst aber von beiden die Werte als String bekommen. Also erstellst du eine neue Methode f├╝r deine Datenabfrage die GET_NAME(_STRING) hei├čt, als Importing ein Objekt ├╝bernimmt und als Ausgabe einen String liefert. In der Methode gibt es ein CASE TYPE OF f├╝r die beiden Interfaces und jeweils die zus├Ątzlich notwendige Konvertierung des Returning-Parameters in einen String. Jetzt kannst du dir noch ├╝berlegen, ob bei einem anderen ├╝bergebenen Objekt, das nicht eines der beiden Interfaces implementiert, ein Fehler ausgel├Âst werden soll oder einfach ein leerer String zur├╝ckgeliefert werden soll. Je nachdem was man damit erreichen m├Âchte macht das eine oder das andere mehr Sinn.
Will man z.B. die Objekte f├╝r eine Listausgabe "serialisieren" macht ein Fehler keinen Sinn. Wenn nichts f├╝r GET_NAME da ist, soll auch nichts angezeigt werden und nicht die Ausgabe abgebrochen werden. Braucht man den Wert hingegen f├╝r die weitere Verabeitung ist eine Exception ein besserer Indikator f├╝r einen inkonsitenten Zustand als ein leerer String.

EDIT:
Der gro├če Vorteil ist, wie schon erw├Ąhnt, dass man ├╝ber diesen Weg die statisch Syntaxpr├╝fung nicht verliert. Wann immer sich eines der beteiligten Objekte/Interfaces derart ├Ąndert, dass man damit nicht mehr wie gewohnt weiterarbeiten kann merkt man das schon beim Aktivieren (oder sp├Ątestens beim Transportieren). Im dynamischen Ansatz (via RTTI und Co.) merkt man den Fehler uU erst am Produktivsystem wenn der Benutzer auf ein Objekt zugreift, dass man in all der Hektik am Testsystem nicht ber├╝cksichtigt hat.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers f├╝r den Beitrag:
Icke0801

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

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Icke0801 hat geschrieben: ÔćĹ
30.04.2022 12:15
Die Klassen haben ├╝ber 20 Interfaces. Deswegen bin ich diesen Weg gegangen. Die Methoden unterscheiden sich vom Namen und den Typen des Returning Parameters.
Du hast also eine Klasse mit n Interfaces und wei├čt nicht, aus welchem Interface du die Methode aufrufst? Das halte ich f├╝r einen grunds├Ątzlichen Designfehler. Ein Interface beschreibt eine Eigenschaft einer Klasse bzw. des daraus resultierenden Objektes und der Kontext des Aufrufes muss zu eben dieser Eigenschaft passen. Wenn du das bedenkst, l├Âst sich dein Problem von selbst.


Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel f├╝r den Beitrag:
Icke0801

Bild
Ralf Wenzel ÔÇó Heuristika SAP-Development
25 Jahre SAP-Entwickler ÔÇó 20 Jahre Freiberufler
Publikationen ÔÇó Ungarische Notation ÔÇó Xing

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von Icke0801 (Specialist / 126 / 97 / 7 ) »
ralf.wenzel hat geschrieben: ÔćĹ
01.05.2022 15:17
Du hast also eine Klasse mit n Interfaces und wei├čt nicht, aus welchem Interface du die Methode aufrufst? Das halte ich f├╝r einen grunds├Ątzlichen Designfehler.
Wer sagt denn sowas? Mein Problem siehe Link
--
Gr├╝├če aus der Endlosschleife
-= Icke =-
abapTools

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von msfox (Specialist / 308 / 50 / 63 ) »
Icke0801 hat geschrieben: ÔćĹ
30.04.2022 08:28

Code: Alles ausw├Ąhlen.

  DATA(object_ref) = cl_abap_typedescr=>describe_by_object_ref( lo_object ).
  DATA(class_desc) = CAST cl_abap_classdescr( object_ref ).
  READ TABLE class_desc->methods ASSIGNING FIELD-SYMBOL(<method>)
                                 WITH KEY name = 'GET_MACHWAS'.
  IF sy-subrc = 0.
    CALL METHOD lo_object->(<method>-name)
      RECEIVING
        result = result.
  ELSE.
    BREAK-POINT.
  ENDIF.
Von welchem Typ ist denn lo_object?
Ist f├╝r GET_MACHWAS() vielleicht ein Alias definiert. Denn normalweise m├╝sste du ja beim Ausf├╝hren der Methode auch das Interface angeben.
Denn CALL METHOD lo_object->(<method>-name) bzw. o_object->GET_MACHWAS() sollte ohne Angabe des Inferfaces nicht funktionieren, wenn daf├╝r in der Klasse kein Alias definiert ist.
--
Trotzdem habe ich den Sinn nicht ganz verstanden.
Jede Methode trotz gleichem Namen in unterschiedlichen Interfaces macht ja etwas anderes. Du willst diese jetzt einfach dynamisch ausf├╝hren. Damit muss ja sichergestellt bleiben, dass, ob die Methode gleich hei├čt, auch immer die gleichen Parameter hat.
Weiterhin geht ja jeglicher Verwendungsnachweis verloren, wenn man so etwas dynamisch macht.

Folgende Benutzer bedankten sich beim Autor msfox f├╝r den Beitrag:
Icke0801


Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von msfox (Specialist / 308 / 50 / 63 ) »
Icke0801 hat geschrieben: ÔćĹ
02.05.2022 06:12
ralf.wenzel hat geschrieben: ÔćĹ
01.05.2022 15:17
Du hast also eine Klasse mit n Interfaces und wei├čt nicht, aus welchem Interface du die Methode aufrufst? Das halte ich f├╝r einen grunds├Ątzlichen Designfehler.
Wer sagt denn sowas? Mein Problem siehe Link
Du sagst so etwas indirekt. Wenn du nur ein Interface mit genau dieser Methode h├Ąttest, w├╝rdest du diese auch "normal" ausf├╝hren.

Folgende Benutzer bedankten sich beim Autor msfox f├╝r den Beitrag:
Icke0801


Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von Icke0801 (Specialist / 126 / 97 / 7 ) »
msfox hat geschrieben: ÔćĹ
02.05.2022 08:37
Du sagst so etwas indirekt. Wenn du nur ein Interface mit genau dieser Methode h├Ąttest, w├╝rdest du diese auch "normal" ausf├╝hren.
Das ist doch gar nicht mein Problem.
Es geht hier um:
Dazu habe ich folgende Fragen:
wie komme ich an den Typen des Returning-Parameters (Inline Deklaration funktioniert hier nicht)
Warum kann ich nicht auf die Interface Methoden ('ZIF_INTERFACE~GET_MACHWAS') zugreifen?
Der Read Table geht nur mit 'GET_MACHWAS'
--
Gr├╝├če aus der Endlosschleife
-= Icke =-
abapTools

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von black_adept (Top Expert / 3947 / 105 / 886 ) »
Moin Icke,

so ganz schlau werde ich aus deiner Frage zwar auch nicht. Aber k├Ânnte es sein, dass du den FuBa SEO_PARAMETER_READ_ALL suchst?

Folgende Benutzer bedankten sich beim Autor black_adept f├╝r den Beitrag:
Icke0801

live long and prosper
Stefan Schm├Âcker

email: stefan@schmoecker.de

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von a-dead-trousers (Top Expert / 4286 / 214 / 1142 ) »
Icke0801 hat geschrieben: ÔćĹ
02.05.2022 11:34
Das ist doch gar nicht mein Problem.
Es geht hier um:
Dazu habe ich folgende Fragen:
wie komme ich an den Typen des Returning-Parameters (Inline Deklaration funktioniert hier nicht)
Warum kann ich nicht auf die Interface Methoden ('ZIF_INTERFACE~GET_MACHWAS') zugreifen?
Der Read Table geht nur mit 'GET_MACHWAS'
Und Ralf, msfox sowie meine Wenigkeit versuchen dir verst├Ąndlich zu machen, dass du einen v├Âllig falschen Ansatz verfolgst.
Wenn du bereits alles in Interfaces organisiert hast, dann verwende doch diese Interfaces f├╝r den Methodenaufruf. Du kannst ja sowieso nicht eine "zentrale" Methode f├╝r die Abfrage bauen, wenn alle Methoden unterschiedliche Parameter haben. Um unter dieser Vorraussetzung "dynamisch" auf die Methoden zuzugreifen musst du erst wieder ein riesiges CASE-Statement, z.B. bezogen auf den Methodennamen oder ├Ąhnliches, verwalten, damit du auf die jeweiligen Daten korrekt zugreifen kannst. Also warum nicht gleich den ganzen dynamischen Ansatz weglassen und ein CASE TYPE OF mit direktem Bezug auf die Interfaces verwenden?

Anyway:
Die Klasse CL_ABAP_CLASSDESCR bietet auch eine Methode GET_METHOD_PARAMETER_TYPE mit der du dir den Datentyp des Returning-Parameters deiner Methode zur├╝ckliefern lassen kannst. Die Liste der Parameter ist Teil des Attributs METHODS in CL_ABAP_CLASSDESCR und der dynamische Aufruf mit LO_OBJECT->('ZIF_INTERFACE~GET_MACHWAS') ist syntaktisch korrekt. Wenn er trotzdem fehlschl├Ągt dann musst du dir die Exception dazu anschauen. Das gleiche gilt ├╝brigens auch f├╝r den READ TABLE, sprich, wenn dein aktuelles Objekt das Interface ZIF_INTERFACE tats├Ąchlich implementiert, gibt es auch einen Eintrag mit 'ZIF_INTERFACE~GET_MACHWAS' in der Tabelle.

Edit:
Ach ja, weil sich der Parameter-Name ja auch noch ├Ąndern kann, wirst du die komplett dynamische Syntax von CALL METHOD mit PARAMETER-TABLE und EXCEPTION-TABLE brauchen. Nur so als Hinweis.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers f├╝r den Beitrag:
Icke0801

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

Re: Dynamischer Methodenaufruf (Teil 327)

Beitrag von Icke0801 (Specialist / 126 / 97 / 7 ) »
Jetzt hab ich verstanden, worauf Ihr hinaus wollt. Danke f├╝r diese Erkl├Ąrungen.
Die Parameter habe ich im Griff. Wie die Exceptions der Methoden dann abgefangen werden, muss ich noch herausfinden.
--
Gr├╝├če aus der Endlosschleife
-= Icke =-
abapTools

Seite 1 von 1

Vergleichbare Themen

2
Antw.
1564
Views
Dynamischer Methodenaufruf mit dynamischer Tabelle
von mark.thk » 12.12.2018 10:34 • Verfasst in ABAP Objects┬«
5
Antw.
4256
Views
Dynamischer Methodenaufruf mit dynamischer Tabelle
von Tommy Nightmare » 08.09.2017 13:23 • Verfasst in ABAP Objects┬«
4
Antw.
19490
Views
Dynamischer Methodenaufruf
von Cola » 20.08.2009 14:55 • Verfasst in ABAP Objects┬«
6
Antw.
2868
Views
Ist ein dynamischer Methodenaufruf m├Âglich?
von Michael.Nett » 14.11.2005 15:21 • Verfasst in ABAP┬« Core
2
Antw.
2381
Views
Dynamischer Methodenaufruf: Methode nicht gefunden
von ralf.wenzel » 08.09.2014 18:20 • Verfasst in ABAP Objects┬«

├ťber diesen Beitrag


Die Frage ist als "gel├Âst" markiert. Den entsprechend Beitrag findest du hier.

Unterst├╝tze die Community und teile den Beitrag f├╝r mehr Leser und Austausch

Newsletter Anmeldung

Keine Beitr├Ąge verpassen! W├Âchentlich versenden wir lesenwerte Beitr├Ąge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsm├Âglichkeiten findest du in unserer Datenschutzerkl├Ąrung.