Abap Objektorientierte Get-Methode

Getting started ... Alles für einen gelungenen Start.
39 Beiträge • Seite 1 von 3 (current) Nächste
39 Beiträge Seite 1 von 3 (current) Nächste

Abap Objektorientierte Get-Methode

Beitrag von Abap Anfänger93 (ForumUser / 1 / 0 / 0 ) »
Hi,
ich lerne seit ca. zwei Wochen abap und habe "ABAP der praktische Einstieg" in der ersten
Woche durchgearbeitet. Nun hatte ich die Aufgabe bekommen, mein kleines Programm, objektorientiert zu programmieren, was auch geklappt hat. Anschließend sollte ich eine get_methode erstellen und den Wert gesamtkosten returnen und genau da liegt der Wurm drin.

mfg AbapAnfänger93

Hier einmal mein Code:

Code: Alles auswählen.

REPORT ZDKL_KLASSEN01.

class lcl_test DEFINITION.
  public SECTION.
    CLASS-METHODS:
      ausgabe_test,
      get_gebuehren_test
          RETURNING VALUE(rv_gesamt_kosten) type zdklteilnehmer02.
endclass.

class lcl_test IMPLEMENTATION.

  method ausgabe_test.
    data ls_test type zdklteilnehmer02.
    data lt_test type STANDARD TABLE OF zdklteilnehmer02.

    data  lv_gesamt_kosten type zdklteilnehmer02.

    WRITE: / 'Namen', 'Kursnamen', 'Preis'.
    ULINE.
    SELECT * FROM zdklteilnehmer02 INTO ls_test where tname is NOT NULL and zzdklkurstitel is not null and tkurspreis is not null.
      WRITE: / ls_test-tname , ls_test-zzdklkurstitel, ls_test-tkurspreis.
    endselect.
    lv_gesamt_kosten = get_gebuehren_test( ).

  endmethod.


  method get_gebuehren_test.
    data lt_test type STANDARD TABLE OF zdklteilnehmer02.
    data ls_test like line of lt_test.
    data gesamt_kosten type i.
    data gebuer type i.
    gebuer = 100.

    SKIP.
    WRITE: / 'Gesamt Kosten'.
    ULINE.
    SELECT * FROM zdklteilnehmer02 INTO table lt_test where tkurspreis is not null and zzdklkurstitel is not null.

    LOOP AT lt_test into ls_test.
      IF ls_test-zzdklkurstitel = 'SAP-FINANZWESEN' or ls_test-zzdklkurstitel = 'NETZWERKTECHNIK' or ls_test-zzdklkurstitel =  'PC-GRUNDLAGEN'.
        gesamt_kosten = ls_test-tkurspreis + gebuer.
        MODIFY lt_test FROM ls_test.
      ENDIF.
      WRITE: / gesamt_kosten.
    ENDLOOP.
     gesamt_kosten = rv_gesamt_kosten.

  endmethod.

endclass.

START-OF-SELECTION.
  lcl_test=>ausgabe_test( ).


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


Re: Abap Objektorientierte Get-Methode

Beitrag von msfox (Specialist / 302 / 50 / 62 ) »

Code: Alles auswählen.

lv_gesamt_kosten = get_gebuehren_test( ).
Macht keinen Sinn, weil danach die Methode zu ende ist.

Code: Alles auswählen.

gesamt_kosten = rv_gesamt_kosten.
Macht auch keinen Sinn, weil rv_gesamt_kosten an der Stell noch leer ist.

Sollte vermutlich

Code: Alles auswählen.

rv_gesamt_kosten = gesamt_kosten.
heißen.

Re: Abap Objektorientierte Get-Methode

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
msfox hat geschrieben:

Code: Alles auswählen.

lv_gesamt_kosten = get_gebuehren_test( ).
Macht keinen Sinn, weil danach die Methode zu ende ist.
stimmt... wobei es ja sein kann dass hier eventuell noch etwas dazukommt.

Re: Abap Objektorientierte Get-Methode

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Also, da ist ja einiges schiefgelaufen. Insbesondere hast du Objektorientierung leider nicht verstanden - das Zeugnis muss ich dir leider so krass ausstellen. Ich weiß, dass es nur eine Übungsaufgabe ist, aber das ist ein Aufsatz in der Schule auch, trotzdem schreibt man drunter "Thema verfehlt" wenn dem so ist. Ich bin ein Freund offener Worte, weil dir das am meisten hilft. Ich will aber nicht nur meckern, sondern auch helfen. Daher folgende Hinweise:

Objektorientierung ist NICHT das Schreiben einer statischen Klasse, in der Methoden definiert sind, die dann prozedural abgearbeitet werden. Es gibt so ein paar Grundregeln, die du beherzigen solltest:

Wenn du keine Instanz hast, brauchst du in der Regel keine Klasse. Dann kannst du das auch einfach in einen Report schreiben. Eine statische Klasse bringt praktisch keine Vorteile. Keine Interfaces, keine Ableitung (Vererbung), etc.

Eine Methode macht EINE Sache, die durch ihren Namen beschrieben wird. Bei dir sehe ich einen SELECT (auch noch in einer SELECT/ENDSELECT-Schleife!) und eine Verdichtung und eine Ausgabe in einer Methode. Das ist von Haus aus schon falsch. Nicht suboptimal, aus OO-Sicht ist das wirklich falsch. "Läuft doch" ist kein Kriterium. Dann machen BEIDE Methoden, die völlig unterschiedlich heißen (get... und ausgabe....) Datenbeschaffung und Ausgabe. So dokumentiert der Name nicht, was die Methode macht, die Methode ist ein Überraschungsei.

Eine GET-Methode sollte den Wert eines Attributes zurückliefen. Eine Methode, die etwas anderes tut, sollte man nicht GET.... nennen. READ wäre deutlich sinniger gewählt. Eine Ausnahme kann man machen, wenn aus dem Namen ersichtlich wird, wenn KEIN Attributwert zurückgeliefert wird (GET_MATNR_FROM_BELEG), aber selbst davon würde ich abraten. Bei einer Methode, die irgendwas anderes macht als die Rückgabe eines Attributes, würde ich zuletzt bei den GET... Methoden suchen.

Methoden sind sehr kurz. Das mögen viele nicht, das hat aber mehrere Gründe, von denen ich nur einen nennen will: Ich habe schon eine Methode aus fünf Zeilen in mehrere aufgeteilt, weil ich einen Fall hatte, wo ich dachte "ich brauche EINE Anweisung in meiner Ableitung anders" - dann muss diese eine Anweisung in eine eigene Methode, sonst kopiere ich Coding beim Redefinieren (was immer eine schlechte Idee ist). Wir haben hier im Projekt eine riesige generische Persistenzschicht, die wahnsinnig viel automatisch macht. Der SELECT aber steht in einer eigenen Methode - weil wir irgendwann auch CLUSTER-Tabellen brauchten, die eben nicht mit SELECT arbeiten.

Außerdem: Einen LOOP würde ich aus Performancegründen immer in ein Feldsymbol machen. SELECT/ENDSELECT-Schleifen sind auch Kappeskram. Besser wäre folgende Struktur:

Verbesserungsvorschlag für den nächsten Versuch:

Eine Methode für die DB-Zugriffe (READ....), dann eine Methode für die Datenaufbereitung (CALC..., MERGE oder DETERMINE...) und dann eine für die Ausgabe. Du kommst auch mit einem SELECT aus, wenn du willst. Oder du machst direkt einen SELECT auf die verdichteten Daten, dann brauchst du zwei. Aber bitte in unterschiedlichen READ-Methoden. Und bitte alles in einer Instanz, nicht in einer statischen Klasse. Die sind für operatives Coding in aller Regel ungeeignet.

Wenn du mir mal die Struktur deiner Tabelle ZDKLTEILNEHMER02 zeigst, kann ich dir mal ein Beispiel schreiben, wie ICH es machen würde. Und so ganz hab ich nicht verstanden, was das Ergebnis des Ganzen sein sollte, das solltest du mir auch noch beschreiben. Achso: Wie viele Datensätze enthält die Tabelle etwa? Also insgesamt. Das ist für die Frage, WIE man selektiert, nicht ganz unwichtig.



Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 2):
tm987456Looper

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Abap Objektorientierte Get-Methode

Beitrag von deejey (Specialist / 418 / 128 / 45 ) »
ralf.wenzel hat geschrieben:Ich bin ein Freund offener Worte, ...
Das ist mein Spruch

Re: Abap Objektorientierte Get-Methode

Beitrag von msfox (Specialist / 302 / 50 / 62 ) »
ralf.wenzel hat geschrieben:Eine Methode für die DB-Zugriffe (READ....),
Richtig schick wäre natürlich für alle DB-Zugriff eine eigene Klasse zu nehmen. Heißt dann DAO (Data Access Object) als Persistenzschicht.*
Hab ich mir angewöhnt. Hat den Vorteil, dass ich bei Unit-Tests einfach die Klasse austausche und die Test gegen Dummy-Daten laufen lassen kann.

*Ja man kann auch die Persistenzschicht generieren lassen, war mir aber zu verworren.
Zuletzt geändert von msfox am 20.02.2019 09:36, insgesamt 1-mal geändert.

Re: Abap Objektorientierte Get-Methode

Beitrag von msfox (Specialist / 302 / 50 / 62 ) »
SaskuAc hat geschrieben:
msfox hat geschrieben:

Code: Alles auswählen.

lv_gesamt_kosten = get_gebuehren_test( ).
Macht keinen Sinn, weil danach die Methode zu ende ist.
stimmt... wobei es ja sein kann dass hier eventuell noch etwas dazukommt.
Jetzt kommt da aber nix, daher sollte die Zeile auch nicht enthalten sein....

Re: Abap Objektorientierte Get-Methode

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
msfox hat geschrieben:*Ja man auch die Persistenzschicht generieren lassen, war mir aber zu verworren.
Hast du da Literatur zu?

Re: Abap Objektorientierte Get-Methode

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
msfox hat geschrieben:
ralf.wenzel hat geschrieben:Eine Methode für die DB-Zugriffe (READ....),
Richtig schick wäre natürlich für alle DB-Zugriff eine eigene Klasse zu nehmen. Heißt dann DAO (Data Access Object) als Persistenzschicht.*
Hab ich mir angewöhnt. Hat den Vorteil, dass ich bei Unit-Tests einfach die Klasse austausche und die Test gegen Dummy-Daten laufen lassen kann.

*Ja man kann auch die Persistenzschicht generieren lassen, war mir aber zu verworren.
Genau sowas haben wir - eine Klasse pro DB-Zugriff und ideal zum Mocken. Die Persistenzschicht, die man sich generieren lassen kann, besteht aus Persistenzklassen. Die hab ich einmal ausprobiert, bin aber schnell an Grenzen gestoßen (kann man hier irgendwo nachlesen, sie lassen keine Klassenattribute zu). Auch bei Massenzugriffen ist das nicht ratsam, weil die Performance runtergeht.

Bei uns ist es so, dass wir eine Klassenhierarchie haben - wir haben alles, was man generalisieren kann, in mehreren Schichten von Oberklassen stehe. Wie z. B. den SELECT. Das macht das Ganze etwas abstrakt (weil man oft mit RTTI bestimmen muss, welchen Typ man überhaupt hat), aber eben auch sehr multifunktionell. Ist einmal richtig Arbeit und bei jeder neuen Tabelle profitiert man davon, weil eine neue DAO-Klasse schnell erzeugt ist (das machen wir inzwischen per Generator).


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Abap Objektorientierte Get-Methode

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
Aso, es geht um diese Persistenzklassen. Danke, hat sich dann erledigt, dann weiß ich Bescheid um was es sich handelt.

Re: Abap Objektorientierte Get-Methode

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ralf.wenzel hat geschrieben: Ich weiß, dass es nur eine Übungsaufgabe ist, aber das ist ein Aufsatz in der Schule auch, trotzdem schreibt man drunter "Thema verfehlt" wenn dem so ist.
und
Objektorientierung ist NICHT das Schreiben einer statischen Klasse, in der Methoden definiert sind, die dann prozedural abgearbeitet werden.
Letzteres ist zwar grundsätzlich zwar richtig, aber ich glaube, dass die Aufgabenstellung so gemeint war wie es bearbeitet wurde --> Thema bei weitem nicht verfehlt. Mit Übungsaufgaben kann man sich an OO langsam herantasten ohne gleich das ganze Thema verstanden haben zu müssen - darum geht es ja beim Lernen. Wenn man z.B. Deutsch als Fremdsprache lernen will fängt man ja auch nicht gleich mit Immanuel Kants "Kritik der reinen Vernunft" an sondern lernt erst mal ein paar grundsätzliche Vokabeln oder ein paar einfache Floskeln wie z.B. "Ich möchte diesen Teppich bitte nicht kaufen".
ralf.wenzel hat geschrieben:Dann kannst du das auch einfach in einen Report schreiben.Eine statische Klasse bringt praktisch keine Vorteile.
Die Aufgabenstellung war nicht eine instanziierbare Klasse zu schreiben. Davon abgesehen haben statische Methoden Vorteile gegenüber FORM-Routinen wegen ihres flexibleren Interfaces.
Eine GET-Methode sollte den Wert eines Attributes zurückliefen. Eine Methode, die etwas anderes tut, sollte man nicht GET.... nennen. READ wäre deutlich sinniger gewählt.Eine Ausnahme kann man machen, wenn aus dem Namen ersichtlich wird, wenn KEIN Attributwert zurückgeliefert wird (GET_MATNR_FROM_BELEG), aber selbst davon würde ich abraten
@Ralf: Die Implikation "Eine Methode die den Wert eines Attributs zurückliefert sollte den Namen GET_... haben" unterschreibe ich dir gerne, aber die umgekehrte nicht. Den Grund hast du ja selber schon hinterher geschoben und im Gegensatz zu dir suche ich durchaus in den GET_ Methoden wenn ich eine Methode finden will, die mir etwas zurückliefern soll.
ralf.wenzel hat geschrieben:Methoden sind sehr kurz.
Was Ralf hoffentlich sagen will ist:" Lange Codeblöcke sind unübersichtlich". Und das gilt nicht nur für Programmierung in Klassen sondern überall wo du Coding findest. Und Abhilf schafft man üblicherweise mit Modularisierung - egal ob nun mit Methoden, Funktionen, FORMs, MACROs oder was auch immer.
ralf.wenzel hat geschrieben:Außerdem: Einen LOOP würde ich aus Performancegründen immer in ein Feldsymbol machen. SELECT/ENDSELECT-Schleifen sind auch Kappeskram. Besser wäre folgende Struktur:
Solche Verallgemeinerungen sind für Newbies nicht hilfreich. Zustimmung für bei der Aussage dass man für einen LOOP ein Feldsymbol verwenden sollte. Die Performance sollte allerdings bei der Wahl, ob man ein Feldsymbol, eine Referenz oder einen Arbeitsbereich verwendet ganz hinten in der Liste stehen. Aber ich gebe Ralf insofern recht, dass es im Allgemeinen wenig andere Gründe gibt, so dass die Performance als dann einziges Kriterium dann doch zur Verwendeung des Feldsymbols führt.
Weiterhin sind SELECT...ENDSELECT-Schleifen auch nicht "Kappeskram". Ja - der 1. Select im Beispiel des TE schon - aber halt auch wieder nicht verallgemeinert. Ich verweise wiederholt auf den Blog von Horst Keller der sich mit Empfehlungen zur Verwendung von SELECT SINGLE und SELECT * .. UP TO 1 ROWS. ENDSELECT befasst.
ralf.wenzel hat geschrieben:Verbesserungsvorschlag für den nächsten Versuch:
ff
Lob an Ralf :)
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Abap Objektorientierte Get-Methode

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
black_adept hat geschrieben:
ralf.wenzel hat geschrieben:Methoden sind sehr kurz.
Was Ralf hoffentlich sagen will ist:" Lange Codeblöcke sind unübersichtlich". Und das gilt nicht nur für Programmierung in Klassen sondern überall wo du Coding findest. Und Abhilf schafft man üblicherweise mit Modularisierung - egal ob nun mit Methoden, Funktionen, FORMs, MACROs oder was auch immer.
Richtig, aber gerade für Methoden gilt die Regel "Jede Methode macht genau EINE Sache" (eine ähnliche Definition für FORM-Routinen ist mir nicht bekannt). Die gilt nicht nur oder speziell in ABAP, sondern grundsätzlich im OO.

Und in einem Punkt muss ich dir widersprechen: Wenn jemand eine "objektorientierte Methode" schreiben soll und eine statische abliefert, ist in meinen Augen das Thema verfehlt.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Abap Objektorientierte Get-Methode

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
ralf.wenzel hat geschrieben:Also, da ist ja einiges schiefgelaufen.
Ralf
Da schreibt jemand, dass er seit zwei Wochen ABAP lernt, stellt eine gezielte Frage und liefert sogar seinen Quellcode dazu :up: und du überrollst ihn mit Persistenzschichten, Feldsymbolen und was du alles in deinem Projekt machst... :roll:

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag (Insgesamt 4):
DeathAndPaindeejeyLooperBeat


Re: Abap Objektorientierte Get-Methode

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Überrollen mit einem Wort wie „Feldsymbol“???

Ich denke, er kann mit den Tipps schon etwas anfangen, zumal ich mich am WE hinsetzen würde und sein Programm in einer deutlich besseren Version schreiben würde. Mit Kommentaren und Unit Tests natürlich. Dann könnte er praktisch sehen, welche Vorteile die Tipps haben. So er denn nachliefert.

Der Blick auf die Persistenzschicht ist ein perspektivischer — um zu erklären, warum man eine Selektion kapseln sollte. Andere mögen da anders sein, aber wenn ich etwas lerne, brauche ich einen solchen Ausblick, um zu verstehen, warum ich etwas auf eine bestimmte Art tun soll. Es ist nichts Schlechtes, wenn man sowas weiß — wenn auch nur sehr vage.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Abap Objektorientierte Get-Methode

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
ralf.wenzel hat geschrieben: Wenn du mir mal die Struktur deiner Tabelle ZDKLTEILNEHMER02 zeigst, kann ich dir mal ein Beispiel schreiben, wie ICH es machen würde.
ralf.wenzel hat geschrieben: Bei uns ist es so, dass wir eine Klassenhierarchie haben - wir haben alles, was man generalisieren kann, in mehreren Schichten von Oberklassen stehe. Wie z. B. den SELECT. Das macht das Ganze etwas abstrakt (weil man oft mit RTTI bestimmen muss, welchen Typ man überhaupt hat), aber eben auch sehr multifunktionell.
Würde ich gerne mal sehen mit der hier schon oft erwähnten generischen Persistenzschicht. Also wenn dir am WE langweilig sein sollte... ;-)

Vergleichbare Themen

1
Antw.
3396
Views
Zugriff aus ABAP auf eine Java-Methode
von crux » 04.06.2007 15:11 • Verfasst in Java & SAP®
1
Antw.
2191
Views
Zugrigff auf eine Java-Methode von einem ABAP aus
von Ornella » 21.03.2005 23:02 • Verfasst in Java & SAP®
4
Antw.
1756
Views
Listausgabe in Methode
von ralf.wenzel » 22.08.2015 14:38 • Verfasst in ABAP Objects®
20
Antw.
11952
Views
Methode GET_SELECTED_ROWS
von Torsten » 06.09.2004 14:40 • Verfasst in ABAP Objects®
1
Antw.
1726
Views
Entscheidungsmaker Methode
von erzoo24 » 04.05.2016 16:07 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

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.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140