Umherspringende Methoden im quelltextbasierten Class Builder

Getting started ... Alles für einen gelungenen Start.
101 Beiträge • Vorherige Seite 6 von 7 (current) Nächste
101 Beiträge Vorherige Seite 6 von 7 (current) Nächste

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
DeathAndPain hat geschrieben:
24.10.2024 15:08

Genauso sagt REFRESH nichts anderes aus als "Leere die folgende interne Tabelle". Weshalb man stattdessen den weniger eindeutigen Befehl CLEAR verwenden muss, erschließt sich mir nicht. Wenn ein Entwickler ernsthaft nicht mehr weiß, was REFRESH bedeutet, dann reicht einmal tippen auf F1, und schon hat er wieder was gelernt.
CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen, hängt schlicht mit Vereinheitlichung zusammen, da CLEAR für alle Arten von Variablen verwendet wird.
"Code lügt nicht ^^"

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


Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
DeathAndPain hat geschrieben:
24.10.2024 18:07

Aber Kopfzeilen finde ich weit weniger schlimm als ihr Ruf. Sie erhöhen halt etwas die Lernkurve für ABAP-Neueinsteiger, das stimmt. Mein Eindruck ist aber, dass viele einfach zu dusslig sind, mit Kopfzeilen umzugehen und daher sagen, Kopfzeilen seien so schlecht.

Egal, so oder so sind sie Geschichte.
Sagt jemand der gern so auf Performance achtet. Kopfzeilen sind schlecht. Ihre Verwendung erfordert a) mehr Speicher b) ist genauso inperformant, wie ein INTO, da die Daten im Speicher kopiert werden müssen.
"Code lügt nicht ^^"

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
black_adept hat geschrieben:
30.10.2024 09:28
Argh. Wenn ich, gerade bei dir, Ralf, "Iterator-ähnliches Konstrukt" lese, rollen sich mir die Zehnägel auf. Es ist mir unverständlich warum man sein Designpatternwissen überall unmotiviert einzusetzen auslebt. SAP bietet durch LOOP mit seinen diversen Ausprägungen bzw durch die SORTED-Tabellentypen doch implizit vorhandene Iteratoren, die wahrscheinlich >95% aller Fälle, wo man einen Iterator benötigt, abdecken. Das ist "programmieren an der Sprache ABAP vorbei".
Why 😱 ?
Ich versuche es mit einem Bild: Stell dir eine Tabelle vor, mit lauter Sätzen, die zueinander in Bezug stehen. Also z. B. eine EKKO, in der Rahmenverträge und Bestellungen zu finden sind. Dann ist mir eine Methode "finde_best_zu_rahmenvertr( )" lieber als ein READ, der nicht erklärt, was er da selektiert, sondern es nur technisch beschreibt.


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
black_adept hat geschrieben:
30.10.2024 09:28
ralf.wenzel hat geschrieben:
30.10.2024 09:06
Wichtige interne Tabellen verwalte ich über ein Iterator-ähnliches Konstrukt
Ralf
Argh. Wenn ich, gerade bei dir, Ralf, "Iterator-ähnliches Konstrukt" lese, rollen sich mir die Zehnägel auf. Es ist mir unverständlich warum man sein Designpatternwissen überall unmotiviert einzusetzen auslebt. SAP bietet durch LOOP mit seinen diversen Ausprägungen bzw durch die SORTED-Tabellentypen doch implizit vorhandene Iteratoren, die wahrscheinlich >95% aller Fälle, wo man einen Iterator benötigt, abdecken. Das ist "programmieren an der Sprache ABAP vorbei".
Why 😱 ?
Einen Iterator mit einem simplen LOOP zu vergleichen ist auch ein wenig am Thema vorbei. Iteratoren bieten, was sonst nur über zusätzliche Codebefehle möglich ist, wie lines etc. Sicher hat SAP hier Codebasis geschaffen, die Iteratoren nicht zwangsläufig erforderlich macht. Das ist schon historisch begründet. Es wäre allerdings auch denkbar, das SAP mal die Codebasis schafft, bei einem Select direkt Objekte zu erzeugen. Was manchen Code viel besser machen würde.
"Code lügt nicht ^^"

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
gtoXX hat geschrieben:
30.10.2024 10:36
Es wäre allerdings auch denkbar, das SAP mal die Codebasis schafft, bei einem Select direkt Objekte zu erzeugen.
Nein.


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von gtoXX (Specialist / 213 / 44 / 36 ) »
ralf.wenzel hat geschrieben:
30.10.2024 10:47
gtoXX hat geschrieben:
30.10.2024 10:36
Es wäre allerdings auch denkbar, das SAP mal die Codebasis schafft, bei einem Select direkt Objekte zu erzeugen.
Nein.


Ralf
Warum? Hätte viele Vorteile.
"Code lügt nicht ^^"

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
gtoXX hat geschrieben:
30.10.2024 11:12
Warum? Hätte viele Vorteile.
Richtig. Aber es ist nicht denkbar, dass sie das macht. Es klappt ja nichtmal ein SWITCH in einer WHERE-Bedingung.


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von black_adept (Top Expert / 4066 / 120 / 934 ) »
gtoXX hat geschrieben:
30.10.2024 10:36
Einen Iterator mit einem simplen LOOP zu vergleichen ist auch ein wenig am Thema vorbei. Iteratoren bieten, was sonst nur über zusätzliche Codebefehle möglich ist, wie lines etc. Sicher hat SAP hier Codebasis geschaffen, die Iteratoren nicht zwangsläufig erforderlich macht. Das ist schon historisch begründet
Ich finde das schon sehr berechtigt. Der Name benennt den eigentliche Zweck eines Iterartors: Es wird durch ihn quasi eine Wohlordnung auf einer Menge erzeugt, die es ermöglicht diese auf eine definierte Weise vollständig zu durchlaufen. Der Designpattern bringt evtl. noch ein paar Zusätze wie das Lines. Aber genau das bietet halt der Sprachumfang von fast allen Sprachen auch und ich würde einen Teufel tun und einen Iterator anlegen, wenn mir die Sprache ein kernelnahes Äquivalent anbietet.
Versteht mich nicht falsch - es gibt durchaus Situationen, wo ich die Iteratorfunktionalität verwenden würde ( z.B. wenn ich den Iterator an eine Methode übergeben kann ). Aber in meiner schon ein paar Jahre andauernden Praxis habe ich das vielleicht ein oder zweimal wirklich benötigt. Die meisten Aufgaben sind halt einfacher gestrickt.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
Ja, das mag sein, aber ich bleibe dabei: Ein sprechendes "get_...." ist in gewissen Fällen als ein technisches READ, wo man erst überlegen muss "was genau sucht der da aus der Tabelle raus?"....


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von tar (ForumUser / 82 / 20 / 27 ) »
ralf.wenzel hat geschrieben:
30.10.2024 12:16
Ja, das mag sein, aber ich bleibe dabei: Ein sprechendes "get_...." ist in gewissen Fällen als ein technisches READ, wo man erst überlegen muss "was genau sucht der da aus der Tabelle raus?"....
Dafür sollte man ja die Zielvariable entsprechend benennen und kann bei komplexeren Dingen auch einfach mal einen Kommentar hinterlassen - gerade bei SELECTs bieten sich da Side-Comments an.

Getter deuten indes wieder auf Objekteigenschaften hin, d.h. statt einem eigenen Iterator (der wohl statisch und komplett unabhängig zu konkreten Objekten einfach nur Tabellenergebnisse zurückliefert), würde ich bspw. eine Bestellklasse aufbauen, die u.a. eine Methode get_auftraege( ) hat, die wiederum zur Bestellung zugehörige Auftragsinstanzen zurückliefert. Da hantierst du direkt mit Entitäten, hast in diesen die jeweils zugehörigen SELECTs, MODIFYs usw. (=> CRUD, ggf. dafür BAPIs usw. nutzen), alle benötigten Eigenschaften und nach außen klare Bezeichnungen und Zusammenhänge.

Das muss man natürlich alles einmal nach und nach aufbauen, kann es dann aber systemweit einheitlich nutzen. Bei Performanceproblemen würde ich die jeweiligen Eigenschaften dann auch nur on-demand dazu lesen lassen.

Folgende Benutzer bedankten sich beim Autor tar für den Beitrag:
DeathAndPain


Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
tar hat geschrieben:
30.10.2024 14:28
Dafür sollte man ja die Zielvariable entsprechend benennen und kann bei komplexeren Dingen auch einfach mal einen Kommentar hinterlassen - gerade bei SELECTs bieten sich da Side-Comments an.
Nein, weil ein SELECT in eine DAO-Klasse hinter ein Interface gehört. Schon der Testbarkeit wegen.
tar hat geschrieben:
30.10.2024 14:28
Getter deuten indes wieder auf Objekteigenschaften hin
GETTER auf Objekteigenschaften gelten bei uns als veraltet, weil man keine Objekteigenschaften abfragt, sondern Objektzustände.


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
tar hat geschrieben:Ich meinte nicht, um lediglich die interne Tabelle zu leeren usw., sondern den gesamten Codeblock, in dem du eben eine interne Tabelle aufbaust, füllst, für irgendwas nutzt und leerst. Das könnte man immer in eine eigene Methode auslagern und dabei eben auf das Leeren verzichten, weil das durch das Verlassen der Methode ohnehin passiert. Je nach Komplexität/Umfang/Verständlichkeit der Methode wird man dies sowieso tun - gerade auch dann, wenn man 100%-ig sicherstellen will, dass im nächsten Durchlauf keine falsch gefüllten Variablen vorhanden sind.
Richtig, und deshalb braucht man den FREE-Befehl auch so selten. Meist lohnt er nicht, da die Routine eh bald zu Ende ist (oder die interne Tabelle noch benötigt wird).
tar hat geschrieben:Kannst du da vielleicht mal einen Benchmark mit jeweils 1000 Wiederholungen fahren mit diesen 3 Varianten?
- Loop mit CLEAR []
- Loop mit FREE
- Untermethode (in der die Tabelle erzeugt und gefüllt wird, aber ohne CLEAR und ohne FREE)
Warum muss ich das machen? Ich habe ja deutlich verlinkt, dass die SAP selbst auch explizit auf meinem Standpunkt steht. Das ist mir an dieser Stelle gut genug. Wenn Du genau wissen möchtest, wieviel das ausmacht, steht es Dir frei, Dir ein entsprechendes Testprogrämmchen zu basteln und gerne auch das Ergebnis hier zum Besten zu geben. Mir ist aber nicht klar, weshalb ich das für Dich machen muss.

Davon abgesehen wäre die Frage, was denn für den FREE spricht. Anders gefragt: Wenn die SAP es schon empfiehlt, warum dann nicht CLEAR nutzen? Kostet doch nix und ist auch nicht länger als der FREE-Befehl (na ja, ein Zeichen). In dem Moment, in dem es nicht um den freigegebenen Speicher geht, fehlt dem FREE-Befehl jeder Vorteil. Er hat aber (neben der Performancesache) den handfesten Nachteil, dem Leser zu suggerieren, dass die betreffende Variable nicht mehr gebraucht werden würde. Wenn das nicht stimmt, wird der Leser irregeführt.
gtoXX hat geschrieben:SAP schreibt im strikten Modus INTO immer als letzten Teil der Select Anweisung vor.
Da ist die Frage, was Du als "strikt" bezeichnest. Ich kenne den "strikten" Modus bei SELECT als den, bei dem man die Felder mit Komma aufzählen und alle Hostvariablen escapen muss. Und in diesem Modus darf durchaus INTO vor FROM stehen.
gtoXX hat geschrieben:CLEAR zu verwenden, wobei die gute Frage ist warum das uneindeutig sein soll, dass kann man eher über REFRESH sagen
Diese Frage lässt sich leicht beantworten: Bei CLEAR geht aus dem Befehl nicht hervor, ob ein Feld oder eine interne Tabelle geleert wird (uneindeutig). REFRESH leert immer eine interne Tabelle und ist damit hundertprozentig eindeutig. Dabei spielt es keine Rolle, ob diese interne Tabelle eine Kopfzeile hat, und genau das macht REFRESH auch für moderne interne Tabellen tauglich.
Ralf hat geschrieben:Ich versuche es mit einem Bild: Stell dir eine Tabelle vor, mit lauter Sätzen, die zueinander in Bezug stehen. Also z. B. eine EKKO, in der Rahmenverträge und Bestellungen zu finden sind. Dann ist mir eine Methode "finde_best_zu_rahmenvertr( )" lieber als ein READ, der nicht erklärt, was er da selektiert, sondern es nur technisch beschreibt.
Es sei denn, die Spaltennamen der internen Tabelle sind so gut gewählt, dass man das direkt aus dem READ ASSIGN erkennen kann.

Das Problem bei Deiner Vorgehensweise besteht darin, dass Du die Abstraktion auf ein Niveau hochschraubst, auf dem sie keine Vorteile mehr bringt. Ihre Nachteile jedoch bestehen fort, und die bestehen darin, dass man nicht mehr sehen kann, was da technisch passiert. Das ist kein Problem, solange alles funktioniert, aber wenn Du mal einen Programmierfehler machst und Deine abstrakten Funktionalitäten nicht mehr so funktionieren, wie sie sollen, ist es erheblich schwerer, die Ursache zu finden, denn dann ist man gezwungen zu ergründen, was da technisch genau passiert.

Ich bin ein ganz großer Fan davon, Programme gut zu untergliedern, Teilfunktionalitäten zu abstrahieren und einzelne Unterroutinen nicht zu groß werden zu lassen. Aber wenn man es übertreibt, kippt der Vorteil ins Gegenteil. Und gerade im Debugger ist eine gut typisierte interne Tabelle erheblich besser verständlich als ein Objekt (das am besten noch einen Baum von Unterobjekten an sich kleben hat).

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
DeathAndPain hat geschrieben:
30.10.2024 16:16
Diese Frage lässt sich leicht beantworten: Bei CLEAR geht aus dem Befehl nicht hervor, ob ein Feld oder eine interne Tabelle geleert wird (uneindeutig).
Das ist auch völlig egal. Es handelt sich um ein Datenobjekt und das wird gelöscht. Dem Löschenden sollte egal sein, welcher Art das Objekt ist.
DeathAndPain hat geschrieben:
30.10.2024 16:16
Das Problem bei Deiner Vorgehensweise besteht darin, dass Du die Abstraktion auf ein Niveau hochschraubst, auf dem sie keine Vorteile mehr bringt.
Ich finde es lesbarer, das reicht mir als Vorteil.
DeathAndPain hat geschrieben:
30.10.2024 16:16
Deine abstrakten Funktionalitäten
😂 Das ist doch nicht abstrakt! Ich schreibe oft genug generisches Coding, DAS ist abstrakt.

Wie sagte mein Mathelehrer, als wir mit quadratischen Gleichungen und p/q-Formeln und so angefangen haben? "Bildet euch nix drauf ein, das ist keine Mathematik, das ist die bürgerliche Form des Rechnens".

Ja, der umgeschulte Maurer, der bisher nur in Reports gelernt hat, Anweisungen untereinander zu schreiben, der wird vielleicht Probleme haben -- wobei es völlig legitim ist, eine interne Tabelle als Objekt zu betrachten.


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

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von DeathAndPain (Top Expert / 1916 / 249 / 407 ) »
ralf.wenzel hat geschrieben:
30.10.2024 16:33
Das ist auch völlig egal. Es handelt sich um ein Datenobjekt und das wird gelöscht. Dem Löschenden sollte egal sein, welcher Art das Objekt ist.
Nein, es ist nicht egal; er muss es wissen, sonst hat er den Code nicht verstanden. Klar lässt sich diese Information leicht beschaffen bzw. sollte bekannt sein, aber REFRESH ist halt eine Verbesserung der Anschaulichkeit, die nichts kostet. Anders ausgedrückt: Über den Vorteil von REFRESH mag man streiten können, aber Nachteile hat er nicht. Damit spricht nichts dagegen, ihn zu verwenden, um die Leerung interner Tabellen von der Leerung einfacher Datenfelder (incl. Strukturen) optisch abzugrenzen.
Ralf hat geschrieben:Wie sagte mein Mathelehrer, als wir mit quadratischen Gleichungen und p/q-Formeln und so angefangen haben? "Bildet euch nix drauf ein, das ist keine Mathematik, das ist die bürgerliche Form des Rechnens".
Ja, damals wurde in der Schule noch Mathematik gemacht. Heutzutage lernen die Schüler selbst im Gymnasium nur noch, die p-q-Formel anzuwenden. Beweise stehen nicht mehr auf dem Lehrplan (und werden allenfalls mal von guten Mathelehrern eingestreut, aber von den Schülern nicht mehr verlangt).
Ralf hat geschrieben:wobei es völlig legitim ist, eine interne Tabelle als Objekt zu betrachten.
Das sehe ich anders, weil nämlich dann die Begriffe durcheinandergehen. Ein Objekt ist definiert als Instanz einer Klasse. Wenn man Begriffe derart mehrdeutig verwendet, entstehen Verwirrung und Missverständnisse.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

Beitrag von ralf.wenzel (Top Expert / 3917 / 199 / 280 ) »
DeathAndPain hat geschrieben:
30.10.2024 20:43
Nein, es ist nicht egal
Doch, du löschst ein Datenobjekt. Ob das ein Feld ist oder eine Struktur oder eine Tabelle, ist völlig unerheblich. Oder erklär mir doch mal, warum es nicht besonderen Löschbefehle für Strukturen gibt. Und da es die nicht gibt: Warum für Tabellen?

REFRESH war ausschließlich im Kontext von Tabellen mit Kopfzeilen sinnvoll, weil deren Name nicht eindeutig war. Klar, CLEAR[] ging auch....
DeathAndPain hat geschrieben:
30.10.2024 20:43
Ralf hat geschrieben:Wie sagte mein Mathelehrer, als wir mit quadratischen Gleichungen und p/q-Formeln und so angefangen haben? "Bildet euch nix drauf ein, das ist keine Mathematik, das ist die bürgerliche Form des Rechnens".
Ja, damals wurde in der Schule noch Mathematik gemacht.
Nein, eben nicht. Du hast meinen Mathelehrer nicht verstanden. Schon damals war p/q-Formel keine Mathematik.
DeathAndPain hat geschrieben:
30.10.2024 20:43
Ralf hat geschrieben:wobei es völlig legitim ist, eine interne Tabelle als Objekt zu betrachten.
Das sehe ich anders, weil nämlich dann die Begriffe durcheinandergehen. Ein Objekt ist definiert als Instanz einer Klasse.
Hä? Ich kann ein Auto, einen Beleg und sonstwas als Objekt betrachten, aber eine Tabelle nicht? Natürlich kann ich aus einer Tabelle ein Objekt machen, indem ich sie in einer Klasse verwalte.

Abzugrenzen ist das vom Begriff des Datenobjektes, den ich oben verwendet habe, was wirklich nur die "nackte" interne Tabelle ist.


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

Vergleichbare Themen

10
Antw.
2821
Views
Top-Includes im Class-Builder
von mwcem » 27.06.2006 16:39 • Verfasst in ABAP Objects®
3
Antw.
5108
Views
Interne Tabelle in Class Builder definieren
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
5
Antw.
6702
Views
Abstrakte Methode im Class Builder anlegen
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
5
Antw.
3231
Views
Class Builder: Default für Meth.param. gepackt mit Dezimalen
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
0
Antw.
2501
Views
Solution Builder (Build Block Builder)
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module

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.