Textelemente und Vererbung, Ideen?
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hallo zusammen,
vielleicht fällt einem von Euch ja eine schöne Lösung für folgendes Szenario ein. Ich beschreib es mal verbal:
Ich habe eine Klasse SUPER und neben vielen anderen Methoden die Methode SUPER->OUTPUT( ), die einen Dialog aufbaut und dabei u.a. einen Text ausgibt.
Dieser Text ist, weil übersetzungsrelevant, als Textelement TEXT-001 der Klasse SUPER angelegt (fürs Beispiel: TEXT-001 = "ALPHA").
Und es gibt Unterklassen von SUPER: SUB1, SUB2, SUB3.
Nun soll SUB1->OUTPUT( ) genau dasselbe tun wie SUPER->OUTPUT( ), nur einen anderen Text ("BETA") verwenden.
Ich könnte den zweiten Text ("BETA") als TEXT-001 der Klasse SUB1 anlegen.
Ohne Redefinition ruft dann aber SUB1->OUTPUT( ) die geerbte Methode SUPER->OUTPUT( ) auf, die auf ihren TEXT-001 zurückgreift, also "ALPHA".
Oder ich redefiniere die Methode OUTPUT() und kopiere das identische(!) Coding aus der SUPER->OUTPUT( ). Dann greift SUB1->OUTPUT( ) nämlich auf TEXT-001 der Klasse SUB1 zurück und benutzt damit "BETA".
Bisher landete ich in meinen Überlegungen am Ende immer in Redefinitionen, die im Grunde identisch zu den Definitionen der Oberklasse sind. Aber schlank und generisch ist das nicht.
Für weitere Ideen dankbar,
Frank
vielleicht fällt einem von Euch ja eine schöne Lösung für folgendes Szenario ein. Ich beschreib es mal verbal:
Ich habe eine Klasse SUPER und neben vielen anderen Methoden die Methode SUPER->OUTPUT( ), die einen Dialog aufbaut und dabei u.a. einen Text ausgibt.
Dieser Text ist, weil übersetzungsrelevant, als Textelement TEXT-001 der Klasse SUPER angelegt (fürs Beispiel: TEXT-001 = "ALPHA").
Und es gibt Unterklassen von SUPER: SUB1, SUB2, SUB3.
Nun soll SUB1->OUTPUT( ) genau dasselbe tun wie SUPER->OUTPUT( ), nur einen anderen Text ("BETA") verwenden.
Ich könnte den zweiten Text ("BETA") als TEXT-001 der Klasse SUB1 anlegen.
Ohne Redefinition ruft dann aber SUB1->OUTPUT( ) die geerbte Methode SUPER->OUTPUT( ) auf, die auf ihren TEXT-001 zurückgreift, also "ALPHA".
Oder ich redefiniere die Methode OUTPUT() und kopiere das identische(!) Coding aus der SUPER->OUTPUT( ). Dann greift SUB1->OUTPUT( ) nämlich auf TEXT-001 der Klasse SUB1 zurück und benutzt damit "BETA".
Bisher landete ich in meinen Überlegungen am Ende immer in Redefinitionen, die im Grunde identisch zu den Definitionen der Oberklasse sind. Aber schlank und generisch ist das nicht.
Für weitere Ideen dankbar,
Frank
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Mit dem Interface könnte ich die Vererbungshierarchie zu Teilen aufheben. Nur hätte ich dann zwei Klassen CL1 und CL2, die beide das Interface IF1 mit der Methode OUTPUT( ) implementieren. Und damit hätte ich zwei Klassen mit textlich zwei identischen Methoden. D.h., am "Coding kopieren" ändert das nix und ich habe auch keine Vererbung bei den anderen Methoden. Oder war das anders gemeint?Unit605 hat geschrieben:Interface?
Nur so ein Gedanke:
Oder Aufruf der Methode SUPER->OUTPUT mit entsprechendem Parameter? z.B. mit einem Attribut/Constante (Referenz die jeweilige Klasse selber) der jeweiligen aufrufenden Klasse?
Ist der Parameter leer, wird der Text der SUPERklasse ausgegeben, ansonsten der Text entsprechende dem Attribut bzw. Referenz?
Oder Aufruf der Methode SUPER->OUTPUT mit entsprechendem Parameter? z.B. mit einem Attribut/Constante (Referenz die jeweilige Klasse selber) der jeweiligen aufrufenden Klasse?
Ist der Parameter leer, wird der Text der SUPERklasse ausgegeben, ansonsten der Text entsprechende dem Attribut bzw. Referenz?
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Ich würde einen ganz anderen Weg gehen: "me" behält ja seine Identität, ist also in SUPER genauso wie in SUB1, egal ob die Methode der Oberklasse ausgeführt wird oder eine Redefinition.
Wenn man also einen CASE bildet, der da sagt "wenn du vom Typ der Unterklasse SUB1 bist, dann zeige Textelement X, wenn du vom Typ der Unterklasse SUB2 bist, zeige Textelement Y" und so weiter....
Wenn man also einen CASE bildet, der da sagt "wenn du vom Typ der Unterklasse SUB1 bist, dann zeige Textelement X, wenn du vom Typ der Unterklasse SUB2 bist, zeige Textelement Y" und so weiter....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo Ralf,
meinst Du, den Case in einer Methode der Oberklasse zu bauen?
Hiesse, beim Bauen des Case sollte ich die Unterklassen kennen und müsste auf die Textelemente derselben direkt durchgreifen. Richtig?
Muss ich mir mal durch den Kopf gehen lassen.
meinst Du, den Case in einer Methode der Oberklasse zu bauen?
Hiesse, beim Bauen des Case sollte ich die Unterklassen kennen und müsste auf die Textelemente derselben direkt durchgreifen. Richtig?
Muss ich mir mal durch den Kopf gehen lassen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Hallo Frank,
schreibe dir doch eine Klasse mit einer statischen Methode, die dir zu einer beliebigen Klasse das jeweilige Textsymbol zurückgibt.
Und rufe dann diese Methode mit Übergabeparameter "me" auf.
Coding etwa so:
schreibe dir doch eine Klasse mit einer statischen Methode, die dir zu einer beliebigen Klasse das jeweilige Textsymbol zurückgibt.
Und rufe dann diese Methode mit Übergabeparameter "me" auf.
Coding etwa so:
Code: Alles auswählen.
Klassennamen bestimmen ( cl_abap_classdescr=>describe_by_ojbect_ref + GET_RELATIVE_NAME oder cl_abap_classdescr=>GET_CLASS_NAME und SPLIT AT '\CLASS=')
Programmnamen der Klasse bestimmen ( FuBa SEO_CLASS_GET_INCLUDE_BY_NAME )
Read Textpool ... into table lt_textpool
(evtl. puffern )
read textpool with key KEY = Text-id
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wie wäre es mit einer "eigenen Lösung" die ähnlich zu TEXT-... funktioniert.
z.B. Eine Methode GET_TEXT( ID_TEXTID = ... ) die in der Superklasse definiert ist.
Man könnte eigene IDs vergeben oder mit ASSIGN arbeiten:
Aufruf:
lg ADT
z.B. Eine Methode GET_TEXT( ID_TEXTID = ... ) die in der Superklasse definiert ist.
Man könnte eigene IDs vergeben oder mit ASSIGN arbeiten:
Code: Alles auswählen.
METHODS get_text
importing
!ID_TEXTID type CSEQUENCE
returning
value(rd_text) type string.Code: Alles auswählen.
METHOD get_text.
field-symbols: <ld_text> type csequence.
assign (ID_TEXTID) to <ld_text>.
if sy-subrc eq 0.
rd_text = <ld_text>.
else.
rd_text = super->get_text( id_textid = id_textid ). "<-- Höher suchen
endif.
ENDMETHOD.Code: Alles auswählen.
me->get_text( id_textid = 'TEXT-001' ).
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 black_adept (Top Expert / 4089 / 127 /
940
)
»
@adt: Ich glaube bei dem Ansatz bist du genau wieder bei dem ursprünglichen Problem von Frank.
Wenn du die Methode GET_TEXTID nicht redefinierst läuft sie im Kontext der Oberklasse und wird dir die TextID der Oberklasse zurückgeben, auch wenn die Unterklasse ein gleichnamiges Textelement besitzt.
Erst die Redefinition lässt die Methode GET_TEXTID im Kontext der Unterklasse laufen.
Und genau diese Redefinition will sich Frank ja wohl sparen.
Wenn du die Methode GET_TEXTID nicht redefinierst läuft sie im Kontext der Oberklasse und wird dir die TextID der Oberklasse zurückgeben, auch wenn die Unterklasse ein gleichnamiges Textelement besitzt.
Erst die Redefinition lässt die Methode GET_TEXTID im Kontext der Unterklasse laufen.
Und genau diese Redefinition will sich Frank ja wohl sparen.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
GastX
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Stimmt, aber er müsste nur relativ wenig Code kopieren und außerdem nur dann wenn er wirklich Elemente aus dem Textpool der Unterklasse verwenden möchte.
Ansonsten kann er alle Texte aus der Hauptklasse nutzen/verwalten und hat trotzdem von jeder Subklasse Zugriff darauf, was ja bei TEXT-... nicht gegeben ist.
Der Vorschlag mit READ TEXTPOOL hat zwar auch was charmantes, nur ist das Bestimmen der Klasse IMHO etwas zu aufwändig für den tatsächlichen Nutzen. Außerdem wird dadurch der Textpool doppelt ins Programm geladen; TEXT-... macht ja genau das Gleiche.
Ansonsten kann er alle Texte aus der Hauptklasse nutzen/verwalten und hat trotzdem von jeder Subklasse Zugriff darauf, was ja bei TEXT-... nicht gegeben ist.
Der Vorschlag mit READ TEXTPOOL hat zwar auch was charmantes, nur ist das Bestimmen der Klasse IMHO etwas zu aufwändig für den tatsächlichen Nutzen. Außerdem wird dadurch der Textpool doppelt ins Programm geladen; TEXT-... macht ja genau das Gleiche.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
GastX
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
Hi,
und Danke fürs Weiterdiskutieren.
Es ist genau wie Stefan sagt: die GET_TEXT() muss ich in den Unterklassen wohl immer redefinieren und das wollte ich vermeiden. Vor allem,da die GET_TEXT() bei allen Unterklassen identisch aussieht. Aber ohne Redefinition wird schlicht der Text aus dem Kontext der Oberklasse gezogen.
Die GET_TEXT() der Oberklasse sieht dann so aus, dass sie direkt auf die Textelemente geht, die GET_TEXT( ) der Unterklassen arbeiten ähnlich wie von ADT beschrieben: hole Textelement, wenn nicht vorhanden, rufe SUPER->GET_TEXT() auf.
Wenn ich das auf Redefinition von GET_TEXT() beschränke, ist das ja doch recht übersichtlich, wenn auch nicht so schön, wie mir eigentlich vorschwebte.
Wenn ich das auf die Spitze treibe, packe ich noch eine abstrakte Klasse über das Ganze mit leerer GET_TEXT( ). Dann kann ich wirklich alle konkreten Klassen mit demselben Coding in der jeweils an der Klasse definierten GET_TEXT() ausstatten. Sollte ich aber per Kommentar erklären, bevor ein Nachfolger denkt "ist eh identisch, dann ist die Redefinition doch für die Tonne".
Ich schaue mir das die Tage nochmal bei meinen produktiven Klassen an. Wenn ich zu mehr Erkenntnissen komme, lasse ich es Euch wissen.
und Danke fürs Weiterdiskutieren.
Es ist genau wie Stefan sagt: die GET_TEXT() muss ich in den Unterklassen wohl immer redefinieren und das wollte ich vermeiden. Vor allem,da die GET_TEXT() bei allen Unterklassen identisch aussieht. Aber ohne Redefinition wird schlicht der Text aus dem Kontext der Oberklasse gezogen.
Die GET_TEXT() der Oberklasse sieht dann so aus, dass sie direkt auf die Textelemente geht, die GET_TEXT( ) der Unterklassen arbeiten ähnlich wie von ADT beschrieben: hole Textelement, wenn nicht vorhanden, rufe SUPER->GET_TEXT() auf.
Wenn ich das auf Redefinition von GET_TEXT() beschränke, ist das ja doch recht übersichtlich, wenn auch nicht so schön, wie mir eigentlich vorschwebte.
Wenn ich das auf die Spitze treibe, packe ich noch eine abstrakte Klasse über das Ganze mit leerer GET_TEXT( ). Dann kann ich wirklich alle konkreten Klassen mit demselben Coding in der jeweils an der Klasse definierten GET_TEXT() ausstatten. Sollte ich aber per Kommentar erklären, bevor ein Nachfolger denkt "ist eh identisch, dann ist die Redefinition doch für die Tonne".
Ich schaue mir das die Tage nochmal bei meinen produktiven Klassen an. Wenn ich zu mehr Erkenntnissen komme, lasse ich es Euch wissen.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Das sollte sie aber nicht.GastX hat geschrieben:...muss ich in den Unterklassen wohl immer redefinieren und das wollte ich vermeiden. Vor allem,da die GET_TEXT() bei allen Unterklassen identisch aussieht.
Da du so etwas wie eine Vererbung/Redefinition der Textelemente vor hast, so etwas aber nicht vorgesehen ist sollte deine GET_TEXT-Methode das Textelement nicht via
Code: Alles auswählen.
lv_output = text-001Code: Alles auswählen.
super->get_text( ... )
lv_output = 'Redefinierter Text'(001). " Kommentar, der auf die Abweichung hinweistDann sieht auch dein Kollege, dass du zunächst die "Standard"-Texte der Oberklasse verwendest und dann hier speziell ein abweichendes.
Außerdem ist der Aufwand ein neues Textelement anzulegen oder zusätzlich eine Methode zu redefinieren und dort auf das Textelement zuzugreifen wohl nur marginal unterschiedlich.
Wenn die von mir vorgeschlagene READ-TEXTPOOL-Version in Betracht gezogen hättest, wäre die fehlende Redefinition dann aus dem selben Grund ein Problem. Denn wenn am Ende das Textelement die einzige Veränderung gegenüber der Superklasse ist, fragt sich dein Kollege "Warum überhaupt eine Vererbung - da hätte ich doch auch gleich die Hauptklasse nehmen können" und das veränderte Textelement kannst du nirgends kommentieren. ( Ok - du könntest das in der Doku erwähnen. Aber ich wie groß ist die Wahrscheinlichkeit dass jemand in einer fremden (nicht von SAP ausgelieferten) Klasse eine Doku findet und sich deshalb in deiner Klasse auf die Suche danach macht )GastX hat geschrieben:Sollte ich aber per Kommentar erklären, bevor ein Nachfolger denkt "ist eh identisch, dann ist die Redefinition doch für die Tonne".
Ich hätte in dem Fall wahrscheinlich ganz klassisch eine Texttabelle angelegt. Mit einem Kennzeichen für jede Unterklasse.
Lässt sich einfach pflegen.
Alle Texte im Überblick.
Übersetzbar.
Änderbar ohne "Programmänderung". (Ja ich weiß, wäre nur LIMU REPS, trotzdem Workbench und kein Customizing).
GET_TEXT muss dann nur der identifier der jeweiligen Sublasse übergeben werden.
just my 2 cm Senf.
Lässt sich einfach pflegen.
Alle Texte im Überblick.
Übersetzbar.
Änderbar ohne "Programmänderung". (Ja ich weiß, wäre nur LIMU REPS, trotzdem Workbench und kein Customizing).
GET_TEXT muss dann nur der identifier der jeweiligen Sublasse übergeben werden.
just my 2 cm Senf.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1639
Views
Views
Ideen für mögliches Abschlussprojekt
von crishi_crd » 11.12.2013 12:53 • Verfasst in ABAP® für Anfänger
von crishi_crd » 11.12.2013 12:53 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1407
Views
Views
7
Antw.
Antw.
1472
Views
Views
Ideen für einen Anfänger Programm
von the_skywalker » 23.08.2021 23:06 • Verfasst in ABAP® für Anfänger
von the_skywalker » 23.08.2021 23:06 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
1126
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 3 Tagen von DeathAndPain 4 / 1270
vor 3 Tagen von DeathAndPain 4 / 1270
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 3 Tagen von DeathAndPain 4 / 1270
vor 3 Tagen von DeathAndPain 4 / 1270