Maschinelle Lohnsteuerberechnung für 2019

Re: Maschinelle Lohnsteuerberechnung für 2019

Das ist jetzt nur als Vorwarnung zu verstehen.
Leider kann ich dir bei deinem konkreten Problem in HR keine Tipps geben.
Ich hoffe aber du weißt, was du hier gerade losgetreten hast.
Die Diskussionen die hier im Forum immer wieder ausbrechen zum Thema OO oder klassisch prozedural können ganze Bibliotheken füllen.

Trotzdem viel Glück.
ADT

Re: Maschinelle Lohnsteuerberechnung für 2019

cgreiner hat geschrieben:c) objekt-orientiert, auch als Funktionsbaustein

Öhhhhm..... Bitte was?


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

Am Postfach kann es nicht liegen - "Ordner ist zu 6% voll (6 von 100 Nachrichten gespeichert)"


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

ralf.wenzel hat geschrieben:Am Postfach kann es nicht liegen - "Ordner ist zu 6% voll (6 von 100 Nachrichten gespeichert)"


Ralf

klappt nicht:

Einige Benutzer konnten nicht hinzugefügt werden, da sie den Empfang Privater Nachrichten deaktiviert haben.

Re: Maschinelle Lohnsteuerberechnung für 2019

cgreiner hat geschrieben:Auf keinen Fall wollte ich eine Diskussion über konventionelle und objekt-orientierte Programmierung anstoßen, glaubt man aber den Anzeigen und Personalvermittler in SAP-Umfeld sind hauptsächlich OO-Entwickler gefragt, weil jeder auf den Zug aufspringen will.

Ja, weil die Anwendungen immer komplexer und anspruchsvoller werden. Der Batch-Input ist halt nicht mehr gefragt und ab einer gewissen Komplexität lohnt sich das. Außerdem muss man das zunehmend in OO geschriebene Coding der SAP verstehen können, wozu (oft auch massive) OO-Kenntnisse erforderlich sind. Ich hatte aber auch schon Fälle, wo ich gefragt wurde, ob ich auch "ABAP-Null-Null" kann. Ohne Witz. Das sind dann Leute, die haben was gesehen und wollen das auch.


Ralf

Re: Maschinelle Lohnsteuerberechnung für 2019

Ein SELECT ist schnell programmiert, eine generische Persistenzschicht ist etwas mehr Arbeit, ist aber wiederverwendbar und kann punktgenau selektieren, wenn man weiß, wie man sowas macht. Und man hat mehrere Teilschichten, die man ändern kann, um mehr oder weniger global Änderungen durchzuführen.


Ralf *steht nicht auf Einweg

Re: Maschinelle Lohnsteuerberechnung für 2019

Ralf hat geschrieben:Ein SELECT ist schnell programmiert, eine generische Persistenzschicht ist etwas mehr Arbeit, ist aber wiederverwendbar und kann punktgenau selektieren, wenn man weiß, wie man sowas macht.

Fragt sich nur, was der Vorteil ist. Mit einem SELECT kann man nämlich auch punktgenau selektieren , und einen einzelnen Befehl (nämlich SELECT) in ein Konstrukt zu kapseln, dessen größter Vorteil es ist, (im günstigsten Fall) das zu können, was der eine Befehl auch kann, finde ich eine äußerst zweifelhafte Entscheidung.

Sobald man eine Sammlung zusammengehörender Daten lesen möchte, zwischen denen ein logischer Zusammenhang besteht, so dass man solch Sammlung häufiger benötigt, macht eine Kapselung Sinn. Aber nicht für den einzelnen SELECT.

Schau Dir doch die Krücken an, die die SAP da liefert. Bei der SAP sind es meist noch Funktionsbausteine, aber ob ich einen FB oder eine statische Klasse aufrufe, die mir die Daten von der Datenbank liest und zurückliefert, macht jetzt nicht den Unterschied. Da brauchste einen einzigen Wert, aber der FB liefert eine komplette Ergebnistabelle mit allen Spalten, so dass Du nach dem Aufruf erst mal einen LOOP darüber machen musst, um dann in der WHERE-Bedingung des LOOPs doch wieder Deine tatsächlich relevanten Bedingungen unterzubringen und anschließend die eine Spalte zu verwerten, die Du eigentlich haben wolltest. Dass der FB dabei noch ohne Ende Customizingoptionen liest und auswertet, von denen Du genau weißt, dass sie für Deine konkrete Anfrage völlig irrelevant sind (selbst wenn die dadurch eingestellte Funktionalität im Unternehmen tatsächlich genutzt wird), kommt erschwerend hinzu.

SaskuAc hat geschrieben:Ich gebe dir zwar recht, dass ein select schnell programmiert und performanter ist. Vorausgesetzt man programmiert den richtig.

Wenn Du Deine Datenzugriffe nicht vernünftig programmierst, dann ist Dein Code so oder so Mist. Ich gebe Dir recht, dass man in dem Bereich sehr häufig Schlamperei sieht. Aber ich behaupte, Schlamperei bekommt man mit einem Methodenaufruf auch hin. (Das halte ich für einen der verbreitetsten Trugschlüsse unter OO-Apologeten, dass OO für besseren Code sorgen würde, indem es die Leute dazu zwingt, sauberer zu arbeiten. Ich halte eher das Gegenteil für zutreffend, denn wenn man mit den OO-Konstrukten schlampig umgeht, dann hat ein anderer hinterher noch viel weniger eine Chance, da durchzusehen, als wenn man dasselbe mit herkömmlicher prozeduraler Programmierung macht.)

SaskuAc hat geschrieben:Und man macht davor noch eine Berechtigungsprüfung ..

Tatsächlich braucht man die in sehr vielen Fällen nicht wirklich, weil die gelesenen Daten nach meiner Erfahrung in den meisten Fällen nicht berechtigungskritisch sind. Und das sage ich als jemand, der (wie Du) im HCM unterwegs ist, wo Berechtigungen generell eine große Rolle spielen.

SaskuAc hat geschrieben:Aber allgemein haben wir die Klasse schon so programmiert, dass die performance sehr gut ist und nur das selektiert was man braucht. ( wie gesagt, wir haben eine Herscharr an Klassen entwickelt - damit man nirgends zu viele Daten selektiert, welche nicht gebraucht werden. )

Das grundsätzliche Problem, das Du Dir damit einhandelst, ist, dass jemand, der den Code liest, verstehen muss, was Deine Klasse macht. Ggf. muss er sich in die Doku Deiner Klasse einlesen oder gar in den Quelltext schauen, wie genau Deine Datumsparameter zu interpretieren sind etc. Das ist eben die Sache mit Methoden: Sie sind eine Form von selbstprogrammierten Befehlen, was bedeutet, dass niemand sie kennt, obwohl er ABAP kann. Noch schlimmer wird es, wenn da ein Bug drin ist, denn dann weißt Du nie genau, ob das wirklich ein Bug ist oder ob Du nur das Sollverhalten der Methode nicht richtig verstanden hast. Bei ABAP-Befehlen stellt sich diese Frage so gut wie gar nicht; da kennst Du das Sollverhalten ganz genau.

Und dass man einen Bug in einem fremden Code finden soll, würde ich sogar als alltägliches Vorkommnis bezeichnen wollen.

Wenn da aber steht:
dann weiß ein Modulfremder zwar möglicherweise nicht, was ich da inhaltlich lese, weil er kein HCM-ler ist, aber selbst er kann auf der Grundlage seines ABAP-Grundwissens ganz präzise sagen, was da technisch passiert. Ist man nicht modulfremd, dann kann man den SELECT damit auf einen Blick zu 100% interpretieren (Da Du HCM-ler bist, habe ich keinen Zweifel, dass Du sofort gesehen und verstanden hast, was ich da lese). Und das, obwohl es kein Einzeiler ist und obwohl Du das umgebende Programm nicht kennst (welches in dem Fall auch nicht existiert, da ich mir dieses Beispiel rasch aus den Fingern gesogen habe).

Das schöne ist, die Klassen puffern einwandfrei, heißt, wenn man einmal einen Datensatz gelesen hat, greift die Klasse danach nicht mehr auf die Datenbank zu, sondern puffert alles intern - was dann sogar wieder schneller ist als der direkte Select.

Und dann bekommst Du komische Werte, weil die Daten auf der Datenbank sich inzwischen verändert haben und Deine Klasse aus ihrem veralteten Puffer liefert. Gewiß wirst Du für solche Fälle irgendeine Form von Refresh-Methode vorgesehen haben, aber da steigt doch sofort wieder die Komplexität, und man muss wissen, wie die Pufferung der Klasse genau arbeitet, und wehe, das, was Du über das Sollverhalten der Klassenpufferung zu wissen glaubst, deckt sich nicht zu 100% mit dem, was sie tatsächlich macht.

Und dann brauchst Du die drei Felder A, B und C. Also musst Du nacheinander drei Methoden aufrufen, für jedes der drei Felder eine. Im Pechfall wird dann dreimal aus derselben Datenbanktabelle gelesen. Oder andersrum Dir reicht Feld A, aber da die Klasse damit rechnet, dass Du im weiteren Verlauf möglicherweise auch die Felder B-Z anfordern wirst, macht sie gleich einen SELECT * in ihren Puffer. Nachher brauchst Du dann tatsächlich Feld H, freilich über einen Schlüssel, der kein Schlüssel der internen Puffertabelle Deiner Klasse ist, wohl aber als Datenbankindex auf der Datenbank existiert... (In dem Zusammenhang: wenn ich aus der HRP1001 lese, dann lese ich fast immer über den Index 3, weil der um Größenordnungen besser ist als der Primärschlüssel der Tabelle. Derjenige SAP-ler, der diesen Index angelegt hat, hat wirklich mal verstanden, wie man mit SQL-Tabellen effizient umgehen muss.)