Umherspringende Methoden im quelltextbasierten Class Builder

Re: Umherspringende Methoden im quelltextbasierten Class Builder

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.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

black_adept hat geschrieben: ↑

Gestern 09:28

ralf.wenzel hat geschrieben: ↑

Gestern 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.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

ralf.wenzel hat geschrieben: ↑

Gestern 10:47

gtoXX hat geschrieben: ↑

Gestern 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.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

gtoXX hat geschrieben: ↑

Gestern 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.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

ralf.wenzel hat geschrieben: ↑

Gestern 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.

Re: Umherspringende Methoden im quelltextbasierten Class Builder

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

ralf.wenzel hat geschrieben: ↑

Gestern 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.