Frage zur redefinierten Methode
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo liebes Forum,
ich hab eine Frage zur Vererbung die mich gerade umtreibt.
Meine Beispielcoding besteht aus 3 Klassen:
- Basisklasse Fahrzeug
- Subklasse PKW
- Runclasse zur Ausgabe
Coding Basisklasse:
Coding Subklasse:
Runclass:
Meine Frage bezieht sich nun auf die redefinierte Methode get_fahrzeug.
Wie bekomme ich es hin, dass ich die zusätzliche Angabe (hier die Anzahl der Sitze) in die gleiche "Zeile" von rt_fahrzeuge mit aufnehme?
Aktuell sieht mein Ergebnis nämlich so aus: Ergänzend dazu habe ich noch eine Frage: Ist es gängige Praxis, dass ich in der Definition der Struktur in der Basisklasse auch Bestandteile mit aufnehme (hier: Anzahl Sitze), die mit der Basisklasse nichts zu tun haben? Oder wie würde man das anders machen?
Vorab vielen Dank für eure Antworten.
ich hab eine Frage zur Vererbung die mich gerade umtreibt.
Meine Beispielcoding besteht aus 3 Klassen:
- Basisklasse Fahrzeug
- Subklasse PKW
- Runclasse zur Ausgabe
Coding Basisklasse:
Code: Alles auswählen.
CLASS zcl_fahrzeug DEFINITION PUBLIC ABSTRACT.
PUBLIC SECTION.
TYPES: BEGIN OF tys_fahrzeug,
hersteller TYPE string,
modell TYPE string,
kennzeichen TYPE string,
anzahl_sitze TYPE i,
END OF tys_fahrzeug,
tyt_fahrzeug TYPE SORTED TABLE OF tys_fahrzeug WITH UNIQUE KEY kennzeichen.
METHODS constructor IMPORTING
i_hersteller TYPE string
i_modell TYPE string
i_kennzeichen TYPE string.
METHODS get_fahrzeug RETURNING VALUE(rt_fahrzeug) TYPE tyt_fahrzeug.
PROTECTED SECTION.
PRIVATE SECTION.
DATA hersteller TYPE string.
DATA modell TYPE string.
DATA kennzeichen TYPE string.
ENDCLASS.
CLASS zcl_fahrzeug IMPLEMENTATION.
METHOD constructor.
hersteller = i_hersteller.
modell = i_modell.
kennzeichen = i_kennzeichen.
ENDMETHOD.
METHOD get_fahrzeug.
rt_fahrzeug = VALUE #( ( hersteller = hersteller kennzeichen = kennzeichen modell = modell ) ).
ENDMETHOD.
ENDCLASS.
Code: Alles auswählen.
CLASS zcl_pkw DEFINITION
PUBLIC
INHERITING FROM zcl_fahrzeug
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
METHODS constructor IMPORTING
i_hersteller TYPE string
i_anzahl_sitze TYPE i
i_modell TYPE string
i_kennzeichen TYPE string.
METHODS get_fahrzeug REDEFINITION.
PROTECTED SECTION.
PRIVATE SECTION.
DATA anzahl_sitze TYPE i.
ENDCLASS.
CLASS zcl_pkw IMPLEMENTATION.
METHOD constructor.
super->constructor( i_hersteller = i_hersteller i_modell = i_modell i_kennzeichen = i_kennzeichen ).
anzahl_sitze = i_anzahl_sitze.
ENDMETHOD.
METHOD get_fahrzeug.
rt_fahrzeug = super->get_fahrzeug( ) .
rt_fahrzeug = VALUE #( BASE rt_fahrzeug ( anzahl_sitze = anzahl_sitze ) ).
ENDMETHOD.
ENDCLASS.
Code: Alles auswählen.
CLASS zcl_runclass DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun .
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_runclass IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
DATA pkw TYPE ref to zcl_pkw.
pkw = new #( i_hersteller = 'BMW' i_kennzeichen = 'HD123' i_modell = 'I4' i_anzahl_sitze = 5 ).
out->write( pkw->get_fahrzeug( ) ).
ENDMETHOD.
ENDCLASS.
Meine Frage bezieht sich nun auf die redefinierte Methode get_fahrzeug.
Wie bekomme ich es hin, dass ich die zusätzliche Angabe (hier die Anzahl der Sitze) in die gleiche "Zeile" von rt_fahrzeuge mit aufnehme?
Aktuell sieht mein Ergebnis nämlich so aus: Ergänzend dazu habe ich noch eine Frage: Ist es gängige Praxis, dass ich in der Definition der Struktur in der Basisklasse auch Bestandteile mit aufnehme (hier: Anzahl Sitze), die mit der Basisklasse nichts zu tun haben? Oder wie würde man das anders machen?
Vorab vielen Dank für eure Antworten.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
hi.
Deine Run-Klasse müsste eine Entscheidung anhand des Typs deines Fahrzeugs treffen.
(Ich gehe davon aus, dass es einmal mehrere "Fahrzeug"-Subklassen in einer Liste geben wird, sonst macht deine Unterteilung wenig Sinn.)
Das Ganze kann man dann auch noch insofern erweitern, dass für eine Listausgabe die spezifischen Spaltenüberschriften nur dann angezeigt werden, wenn ein Objekt des jeweiligen Typs in der Liste existiert.
Die Spalten selbst müssen dann jedoch in der Ausgabestruktur (z.B. für ein ALV) immer vorhanden sein oder man muss sich eine eigene dynamische Ausgabe überlegen.
Deine Run-Klasse müsste eine Entscheidung anhand des Typs deines Fahrzeugs treffen.
Code: Alles auswählen.
loop at lt_fahrzeug assigning field-symbol(<lr_fahrzeug>).
* (in ALV) Neue Zeile in Ausagabetabelle
* Die Spalten des Fahrzeugs verarbeiten.
case type of <lr_fahrzeug>.
when type zcl_pkw into data(lr_pkw).
* Die zusätzlichen Spalten des PKW verarbeiten.
when type zcl_lkw into data(lr_lkw).
* Die zusätzlichen Spalten des LKW verarbeiten.
when ...
...
endcase.
* (in write-Liste) Zeilenumbruch
endloop.Das Ganze kann man dann auch noch insofern erweitern, dass für eine Listausgabe die spezifischen Spaltenüberschriften nur dann angezeigt werden, wenn ein Objekt des jeweiligen Typs in der Liste existiert.
Die Spalten selbst müssen dann jedoch in der Ausgabestruktur (z.B. für ein ALV) immer vorhanden sein oder man muss sich eine eigene dynamische Ausgabe überlegen.
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
Anstatt bei get_fahrzeug( ) eine interne Tabelle zurückzugeben, solltest du hier eine Struktur zurückgeben. Die verwaltest ja keine Liste von Fahrzeugen in einer Instanz sondern lediglich ein Fahrzeug pro Objekt.
Diese Struktur kannst du dann in deiner Subklasse um Informationen erweitern, wie du das ja bereits mit der Tabelle gemacht hast. Du musst nur die VALUE Befehle anpassen, ein paar Klammern löschen.
Gängige Praxis bezüglich Typisierung/Definition von Strukturen? Schwierig. In der Praxis habe ich diesen speziellen Fall eher selten. Würde mir hier um den "richtigen" Ort auch nicht den Kopf zerbrechen. Wenn du dich mit Interfaces beschäftigst, wird in deinem Kopf eh wieder alles umgeworfen =)
Code: Alles auswählen.
METHODS get_fahrzeug RETURNING VALUE(rt_fahrzeug) TYPE tys_fahrzeug.
Gängige Praxis bezüglich Typisierung/Definition von Strukturen? Schwierig. In der Praxis habe ich diesen speziellen Fall eher selten. Würde mir hier um den "richtigen" Ort auch nicht den Kopf zerbrechen. Wenn du dich mit Interfaces beschäftigst, wird in deinem Kopf eh wieder alles umgeworfen =)
Ich versteh auch ned ganz warum jetzt die eigentlichen Attribute eines Kraftfahrzeugs in einer Struktur stecken wenn sie eigentlich (IMO) eher Instanzattribute sein sollen.
Ich würde in dem Fall die get_fahrzeug als (statische) CLASS-METHOD machen (wenn du den Ansatz mit der Strukturrückgabe machen willst) oder hergehen und die (bisher in der Struktur liegenden Attribute) in die PUBLIC SECTION mit dem Zusatz READ ONLY verfrachten bzw dynamische get-ter Instanzmethoden bauen wenn du die Werte abfragen willst.
Der Vorteil von OOP ist ja gerade, dass du ein Objekt baust und es mit Leben (Werten) füllst. In deinem Fall wurde zwar OOP verwendet, aber dennoch der klassiche Prozedurale Ansatz der "Werte-erstellung" weitergeführt. Im Endeffekt ist deine get_fahrzeug ja nur dafür da die Struktur, deren Bestandteile Instanzattribute sein sollen, mit Werten zu bestücken und zurück zu geben.
edit:
Definition der Struktur in der Basisklasse auch Bestandteile mit aufnehme (hier: Anzahl Sitze), die mit der Basisklasse nichts zu tun haben?
Nö, macht ja auch keinen Sinn 😅
Der Grund warum man OOP macht ist die Kapselung und Polymorphismus. Kapselung bedeutet vereinfacht gesagt du kannst Attribute/Felder für den äußeren Zugriff "ausblenden" bzw den Zugriff darauf verweigern. Ein Kundenobjekt kann eine Feld haben was nur intern verwendet werden soll (GUID bspw), das öffentlich zu zeigen macht keinen Sinn bzw kann (unter Umständen) auch gar nicht gewünscht sein. Mit OOP kann man das verhinden - indem man diese Attribut in die PRIVATE SECTION schreibt.
Der Polymorphismus ist dafür gedacht um eine generalisierte Version zu erstellen und davon Ableitungen zu machen. Als doofes Beispiel: Du hast eine generelle (all-purpose) Liste von Kraftfahrzeugen (PKWs, LKWs, Motorrädern, ...) und du willst alle in eine Liste packen und entsprechend ihrers speziellen Typs verarbeiten. Dann erstellst du eine interne Tabelle von deinem Basistypen und APPENDest oder INSERTest mit VALUE#(...) deine Einträge. In der Ausgabe kannst du dann in einer LOOP fahrzeug_list INTO DATA(fahrzeug) ... ENDLOOP über eine CASE fahrzeug Verweigung auf TYPE pkw, TYPE lkw, TYPE motorrad die entsprechende Behandlung machen.
Bei OOP schaut man darauf, dass in der Basisklasse nur Attribute vorhanden sind, die ALLE abgeleiteten Klassen teilen und in den Ableitungen packt man die jeweligen spezifischen Attribute dazu. Soweit ich weiß gibt es zwar den Ansatz in der Basisklasse auch Felder zu definieren, die "weiter unten" vereinzelt, aber nicht in allen Ableitungen, verwendet werden - ich hab dafür allerdings nie den Grund gesehen.
Ich würde in dem Fall die get_fahrzeug als (statische) CLASS-METHOD machen (wenn du den Ansatz mit der Strukturrückgabe machen willst) oder hergehen und die (bisher in der Struktur liegenden Attribute) in die PUBLIC SECTION mit dem Zusatz READ ONLY verfrachten bzw dynamische get-ter Instanzmethoden bauen wenn du die Werte abfragen willst.
Der Vorteil von OOP ist ja gerade, dass du ein Objekt baust und es mit Leben (Werten) füllst. In deinem Fall wurde zwar OOP verwendet, aber dennoch der klassiche Prozedurale Ansatz der "Werte-erstellung" weitergeführt. Im Endeffekt ist deine get_fahrzeug ja nur dafür da die Struktur, deren Bestandteile Instanzattribute sein sollen, mit Werten zu bestücken und zurück zu geben.
edit:
Definition der Struktur in der Basisklasse auch Bestandteile mit aufnehme (hier: Anzahl Sitze), die mit der Basisklasse nichts zu tun haben?
Nö, macht ja auch keinen Sinn 😅
Der Grund warum man OOP macht ist die Kapselung und Polymorphismus. Kapselung bedeutet vereinfacht gesagt du kannst Attribute/Felder für den äußeren Zugriff "ausblenden" bzw den Zugriff darauf verweigern. Ein Kundenobjekt kann eine Feld haben was nur intern verwendet werden soll (GUID bspw), das öffentlich zu zeigen macht keinen Sinn bzw kann (unter Umständen) auch gar nicht gewünscht sein. Mit OOP kann man das verhinden - indem man diese Attribut in die PRIVATE SECTION schreibt.
Der Polymorphismus ist dafür gedacht um eine generalisierte Version zu erstellen und davon Ableitungen zu machen. Als doofes Beispiel: Du hast eine generelle (all-purpose) Liste von Kraftfahrzeugen (PKWs, LKWs, Motorrädern, ...) und du willst alle in eine Liste packen und entsprechend ihrers speziellen Typs verarbeiten. Dann erstellst du eine interne Tabelle von deinem Basistypen und APPENDest oder INSERTest mit VALUE#(...) deine Einträge. In der Ausgabe kannst du dann in einer LOOP fahrzeug_list INTO DATA(fahrzeug) ... ENDLOOP über eine CASE fahrzeug Verweigung auf TYPE pkw, TYPE lkw, TYPE motorrad die entsprechende Behandlung machen.
Bei OOP schaut man darauf, dass in der Basisklasse nur Attribute vorhanden sind, die ALLE abgeleiteten Klassen teilen und in den Ableitungen packt man die jeweligen spezifischen Attribute dazu. Soweit ich weiß gibt es zwar den Ansatz in der Basisklasse auch Felder zu definieren, die "weiter unten" vereinzelt, aber nicht in allen Ableitungen, verwendet werden - ich hab dafür allerdings nie den Grund gesehen.
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
Guter Einwand.
Es macht nicht viel Sinn in der Hauptklasse eine Struktur für alle Unterklassen zu halten die man sukzessive (mit jeder neuen Unterklasse) erweitert.
Man kann aber in der Hauptklasse eine Struktur für die spezifischen Felder definieren und diese dank "Protected" oder "Public" den Unterklassen zur Verfügung stellen. Die Unterklassen definieren wiederum ihre jeweiligen Strukturen, entweder nur mit den spezifischen Feldern oder inklusive der Felder der Hauptklasse indem man diese als INCLUDE einbindet. Die spezifische Rückgabe ist dann aber nicht durch die Hauptklasse möglich sondern nur in den Unterklassen.
In solchen Fällen, wenn man statische Strukturen für z.B. Listausgaben haben möchte, macht eine Redefinition nicht viel Sinn.
P.S.: Wenn man sich schon die Mühe macht eine Struktur zu definieren, dann kann man diese IMHO auch gleich verwenden anstatt alle Bestandteile wieder extra als Attribut auszuführen.
Es macht nicht viel Sinn in der Hauptklasse eine Struktur für alle Unterklassen zu halten die man sukzessive (mit jeder neuen Unterklasse) erweitert.
Man kann aber in der Hauptklasse eine Struktur für die spezifischen Felder definieren und diese dank "Protected" oder "Public" den Unterklassen zur Verfügung stellen. Die Unterklassen definieren wiederum ihre jeweiligen Strukturen, entweder nur mit den spezifischen Feldern oder inklusive der Felder der Hauptklasse indem man diese als INCLUDE einbindet. Die spezifische Rückgabe ist dann aber nicht durch die Hauptklasse möglich sondern nur in den Unterklassen.
Code: Alles auswählen.
CLASS zcl_fahrzeug DEFINITION ABSTRACT.
PUBLIC SECTION.
TYPES: BEGIN OF tys_fahrzeug,
hersteller TYPE string,
modell TYPE string,
kennzeichen TYPE string,
END OF tys_fahrzeug.
METHODS get_fahrzeug_data RETURNING VALUE(rs_fahrzeug) TYPE tys_fahrzeug.
METHODS constructor IMPORTING id_hersteller TYPE string
id_modell TYPE string
id_kennzeichen TYPE string.
PROTECTED SECTION.
PRIVATE SECTION.
DATA gs_fahrzeug TYPE tys_fahrzeug.
ENDCLASS.
CLASS zcl_fahrzeug IMPLEMENTATION.
METHOD constructor.
me->gs_fahrzeug-hersteller = id_hersteller.
me->gs_fahrzeug-modell = id_modell.
me->gs_fahrzeug-kennzeichen = id_kennzeichen.
ENDMETHOD.
METHOD get_fahrzeug_data.
rs_fahrzeug = me->gs_fahrzeug.
ENDMETHOD.
ENDCLASS.
CLASS zcl_pkw DEFINITION INHERITING FROM zcl_fahrzeug CREATE PUBLIC.
PUBLIC SECTION.
TYPES: BEGIN OF tys_pkw,
anzahl_sitze TYPE i,
END OF tys_pkw.
TYPES BEGIN OF tys_fahrzeug_pkw.
INCLUDE TYPE tys_fahrzeug AS fahrzeug.
INCLUDE TYPE tys_pkw AS pkw.
TYPES END OF tys_fahrzeug_pkw.
METHODS constructor IMPORTING id_hersteller TYPE string
id_anzahl_sitze TYPE i
id_modell TYPE string
id_kennzeichen TYPE string.
METHODS get_pkw_data RETURNING VALUE(rs_pkw) TYPE tys_fahrzeug_pkw.
PROTECTED SECTION.
PRIVATE SECTION.
DATA gs_pkw TYPE tys_pkw.
ENDCLASS.
CLASS zcl_pkw IMPLEMENTATION.
METHOD constructor.
super->constructor( id_hersteller = id_hersteller
id_modell = id_modell
id_kennzeichen = id_kennzeichen ).
me->gs_pkw-anzahl_sitze = id_anzahl_sitze.
ENDMETHOD.
METHOD get_pkw_data.
rs_pkw-fahrzeug = me->get_fahrzeug_data( ).
rs_pkw-pkw = me->gs_pkw.
ENDMETHOD.
ENDCLASS.P.S.: Wenn man sich schon die Mühe macht eine Struktur zu definieren, dann kann man diese IMHO auch gleich verwenden anstatt alle Bestandteile wieder extra als Attribut auszuführen.
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
@a-dead-trouser gibt es einen Grund warum es (in ABAP) sinnvoll ist die eigentlichen Instanzattribute, wie in diesem Beispiel etwa Hersteller und Co nicht, als einzelne Felder sondern als gesamter Typ zu machen?
Ich komm eigentlich aus der .NET Ecke und bin C# vorgeschädigt und mach ABAP nur wegen meiner Arbeit seit gut 5 Jahren. Für mich ist es etwas sinnlos das so zu machen da (hier der Vergleich zu C#) es doch viel umständlicher ist auf das Instanzobjekt zu greifen, davon die Getter Methode aufzurufen und dann auf das Resultat wieder zuzugreifen und dann erst das Attribute "in den Finger zu haben" anstelle direkt am InstanzObjekt auf das Attribut zugreifen zu können.
Also quasi:
data(attribut) = instanzObject->get_attribute()-instanzAttribut
bzw
data(attribute) = instanzObject->get_attribute()
data(attribut) = attribute-instanzAttribut
vs
data(attribut) = InstanzObjekt-InstanzAttribut
oder ist das so ein "KDA" (kommt drauf an) Fall und ist nur an dem speziellen Beispiel ungut kann aber manchmal sinnvoll sein?
Ich komm eigentlich aus der .NET Ecke und bin C# vorgeschädigt und mach ABAP nur wegen meiner Arbeit seit gut 5 Jahren. Für mich ist es etwas sinnlos das so zu machen da (hier der Vergleich zu C#) es doch viel umständlicher ist auf das Instanzobjekt zu greifen, davon die Getter Methode aufzurufen und dann auf das Resultat wieder zuzugreifen und dann erst das Attribute "in den Finger zu haben" anstelle direkt am InstanzObjekt auf das Attribut zugreifen zu können.
Also quasi:
data(attribut) = instanzObject->get_attribute()-instanzAttribut
bzw
data(attribute) = instanzObject->get_attribute()
data(attribut) = attribute-instanzAttribut
vs
data(attribut) = InstanzObjekt-InstanzAttribut
oder ist das so ein "KDA" (kommt drauf an) Fall und ist nur an dem speziellen Beispiel ungut kann aber manchmal sinnvoll sein?
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
In ABAP werden sehr oft Listausgaben verwendet und da benötigt man statische Strukturen (wenn man sich nicht mit dynamischen herumschlagen möchte). Da ist es dann oft einfacher "zusammengehörende" Attribute gleich als Struktur zu definieren um sie dann wiederverwenden zu können, so wie in dem konkreten Beispiel (oder am Besten gleich global im DDIC).Radinator hat geschrieben: ↑15.05.2025 13:05gibt es einen Grund warum es (in ABAP) sinnvoll ist die eigentlichen Instanzattribute, wie in diesem Beispiel etwa Hersteller und Co nicht, als einzelne Felder sondern als gesamter Typ zu machen?
Ich komm eigentlich aus der .NET Ecke und bin C# vorgeschädigt und mach ABAP nur wegen meiner Arbeit seit gut 5 Jahren. Für mich ist es etwas sinnlos das so zu machen da (hier der Vergleich zu C#) es doch viel umständlicher ist auf das Instanzobjekt zu greifen, davon die Getter Methode aufzurufen und dann auf das Resultat wieder zuzugreifen und dann erst das Attribute "in den Finger zu haben" anstelle direkt am InstanzObjekt auf das Attribut zugreifen zu können.
Aber ja, wenn man die Zeit hat und es "schön" machen möchte, sollte man sich die Arbeit antun und die einzelnen Felder bzw. Attribute dann doch wieder mit GET- und SET-Methoden ausstatten. Jene die nach Einem (auch man selbst) kommen und das dann debuggen sollen, werden es zu schätzen wissen.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Radinator
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 ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Also, ihr könnt mich ja totschlagen, aber ich würde das ohnehin ganz anders machen.
Erstens: Die Aussage "Deine Run-Klasse müsste eine Entscheidung (...) treffen" ist eine schlechte Möglichkeit. Es sollte eine Factory-Klasse geben, die diese Entscheidung trifft, im Aufrufer hat die in meinen Augen nichts zu suchen.
Wenn unterschiedliche Fahrzeugtypen unterschiedliche Eigenschaften haben, würde ich die Fahrzeugtypen (zcl_pkw/zcl_lkw/...) in einem Objekt verwalten, das seinerseits eine Liste von Objekten verwaltet, für jede Eigenschaft ein Objekt. Diese Objekte werden als Tabelle (Zeilentyp "ref to object") zurückgegeben. Über diese Tabelle kann man loopen und die Eigenschaften auslesen.
Das klingt oversized, aber das hier ist ja wohl nur ein Beispiel und für größere Konstruktionen eben angepasst. Dann ist es dem Fahrzeugobjekt eben völlig egal, wie viele und welche Eigenschaften von welchem Typ es hat.
Ralf
Erstens: Die Aussage "Deine Run-Klasse müsste eine Entscheidung (...) treffen" ist eine schlechte Möglichkeit. Es sollte eine Factory-Klasse geben, die diese Entscheidung trifft, im Aufrufer hat die in meinen Augen nichts zu suchen.
Wenn unterschiedliche Fahrzeugtypen unterschiedliche Eigenschaften haben, würde ich die Fahrzeugtypen (zcl_pkw/zcl_lkw/...) in einem Objekt verwalten, das seinerseits eine Liste von Objekten verwaltet, für jede Eigenschaft ein Objekt. Diese Objekte werden als Tabelle (Zeilentyp "ref to object") zurückgegeben. Über diese Tabelle kann man loopen und die Eigenschaften auslesen.
Das klingt oversized, aber das hier ist ja wohl nur ein Beispiel und für größere Konstruktionen eben angepasst. Dann ist es dem Fahrzeugobjekt eben völlig egal, wie viele und welche Eigenschaften von welchem Typ es hat.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
@Ralf
Ich glaube du vermischt hier die einzelnen Fahrzeuge (Objekte) mit Listen von Fahrzeugen. So wie ich das verstanden habe soll ZCL_PKW genau ein Fahrzeug abbilden (die TYPE TABLE OF Definition macht IMHO nicht viel Sinn hier) und in der Run-Klasse sollen (später vielleicht einmal) mehrere Fahrzeuge verwaltet werden können. Sonst macht die nämlich nicht viel Sinn. Die Bezeichnung ist da zugegeben auch nicht allzu gut gewählt. Ich hätte das irgendwie ZCL_FAHRZEUG_LIST genannt oder ZCL_FUHRPARK.
Was meine Aussage "Deine Run-Klasse müsste eine Entscheidung (...) treffen" betrifft: Irgendwo muss man, für eine generische (List-)ausgabe von Objekten (TYPE [TABLE OF] REF TO) eine Unterscheidung treffen, wie die Daten verarbeitet werden sollen. Dafür habe ich das CASE TYPE OF als Beispiel angeführt. Wo das am Ende passiert ist natürlich eine Designfrage. Im konkreten Beispiel ging es um die Run-Klasse die diese Unterscheidung benötigt. Das in ZCL_FAHRZEUG zu machen führt die ganze Vererbung ad-absurdum, da hier die Superklasse alle Subklassen bzw. deren Attribute kennen müsste was uU zu rekursiven Definitionen führt und man vermeiden sollte.
Ich glaube du vermischt hier die einzelnen Fahrzeuge (Objekte) mit Listen von Fahrzeugen. So wie ich das verstanden habe soll ZCL_PKW genau ein Fahrzeug abbilden (die TYPE TABLE OF Definition macht IMHO nicht viel Sinn hier) und in der Run-Klasse sollen (später vielleicht einmal) mehrere Fahrzeuge verwaltet werden können. Sonst macht die nämlich nicht viel Sinn. Die Bezeichnung ist da zugegeben auch nicht allzu gut gewählt. Ich hätte das irgendwie ZCL_FAHRZEUG_LIST genannt oder ZCL_FUHRPARK.
Was meine Aussage "Deine Run-Klasse müsste eine Entscheidung (...) treffen" betrifft: Irgendwo muss man, für eine generische (List-)ausgabe von Objekten (TYPE [TABLE OF] REF TO) eine Unterscheidung treffen, wie die Daten verarbeitet werden sollen. Dafür habe ich das CASE TYPE OF als Beispiel angeführt. Wo das am Ende passiert ist natürlich eine Designfrage. Im konkreten Beispiel ging es um die Run-Klasse die diese Unterscheidung benötigt. Das in ZCL_FAHRZEUG zu machen führt die ganze Vererbung ad-absurdum, da hier die Superklasse alle Subklassen bzw. deren Attribute kennen müsste was uU zu rekursiven Definitionen führt und man vermeiden sollte.
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 ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Ich schrieb nicht von Listen von Fahrzeugen, sondern Listen von Eigenschaften in EINEM KONKRETEN Fahrzeug.
Natürlich braucht die Run-Klasse die Unterscheidung, sie muss diese aber nicht implementieren. Das sollte sie auch nicht, weil das dann jeder Aufrufer machen muss. Das ist doppeltes Coding.
Ich schrieb auch nicht, dass die Oberklasse das machen sollte, sondern eine Factory-Klasse.
Wenn ich dir nicht so wohlgesonnen wäre, wäre der erste Satz meiner Antwort gewesen „Liest du manchmal auch, was du kommentierst?“…
Ralf
Natürlich braucht die Run-Klasse die Unterscheidung, sie muss diese aber nicht implementieren. Das sollte sie auch nicht, weil das dann jeder Aufrufer machen muss. Das ist doppeltes Coding.
Ich schrieb auch nicht, dass die Oberklasse das machen sollte, sondern eine Factory-Klasse.
Wenn ich dir nicht so wohlgesonnen wäre, wäre der erste Satz meiner Antwort gewesen „Liest du manchmal auch, was du kommentierst?“…
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
Liste von Eigenschaften ... hmmm ... daran hatte ich gar nicht gedacht bzw. überlesen. 😞ralf.wenzel hat geschrieben: ↑16.05.2025 09:42Ich schrieb nicht von Listen von Fahrzeugen, sondern Listen von Eigenschaften in EINEM KONKRETEN Fahrzeug.
Du meinst also die Factory bestimmt, welche Eigenschaften(-objekte) die einzelnen Fahrzeuge erhalten? Also es gibt nur die ZCL_FAHRZEUG-Klasse und über die konkret zugewiesenen Eigenschaften ergibt sich ob es ein PKW oder LKW ist? Ja, ist natürlich auch möglich. Dann hat man aber eine relative intelligente Factory und löst damit eine "tiefe" Vererbung (ZCL_PKW, ZCL_LKW, etc. ) auf. Ich persönlich mag es aber lieber wenn ich Klassen auf einem Blick ansehe welche Funktion sie haben und nicht in einer Liste von Eigenschaften das raussuchen muss was mir zusagt. Deswegen arbeite ich auch immer stärker mit Interfaces wo ich mir per CAST die (Teil-)Informationen die ich brauche direkt aus dem Objekte rausholen kann. Vermutlich hab ich deswegen auch deinen Ansatz mit der Liste der Eigenschaften nicht sofort behirnt.ralf.wenzel hat geschrieben: ↑16.05.2025 09:42Ich schrieb auch nicht, dass die Oberklasse das machen sollte, sondern eine Factory-Klasse.
Danke 😇ralf.wenzel hat geschrieben: ↑16.05.2025 09:42Wenn ich dir nicht so wohlgesonnen wäre, wäre der erste Satz meiner Antwort gewesen „Liest du manchmal auch, was du kommentierst?“…
Zuletzt geändert von a-dead-trousers am 16.05.2025 10:48, insgesamt 1-mal geändert.
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 ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
Das ist der Sinn einer Factory 😉 Dass dieser Entscheidungs- und Instanziierungs-Prozess zentralisiert, aber unabhängig vom Aufrufer UND den konkreten Klassen implementiert ist. Dann muss man die Aufrufer nicht anfassen und die konkreten Objekte auch nicht, wenn sich ein neues dazugesellt. Entweder die Ermittlung des konkreten Typs ist algorithmisch (dann muss man die Factory nichtmal anpassen) oder durch einen Case, dann muss man die Factory erweitern -- und natürlich die neue konkrete Klasse schreiben.a-dead-trousers hat geschrieben: ↑16.05.2025 10:40Du meinst also die Factory bestimmt, welche Eigenschaften(-objekte) die einzelnen Fahrzeuge erhalten? Also es gibt nur die ZCL_FAHRZEUG-Klasse und über die konkret zugewiesenen Eigenschaften ergibt sich ob es ein PKW oder LKW ist? Ja, ist natürlich auch möglich. Dann hat man aber eine relative intelligente Factory und löst damit eine "tiefe" Vererbung (ZCL_PKW, ZCL_LKW, etc. ) auf.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
4910
Views
Views
1
Antw.
Antw.
1802
Views
Views
4
Antw.
Antw.
2053
Views
Views
2
Antw.
Antw.
1991
Views
Views
1
Antw.
Antw.
2018
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.
Aktuelle Forenbeiträge
Unbeantwortete Forenbeiträge
Nutzung UserExit COOM0003 für Abrechnungsvorschriften Aufträge
vor 5 Tagen von fico_fschluesener 1 / 796
vor 5 Tagen von fico_fschluesener 1 / 796