Gehaltsvorstellungen SAP ABAP-Entwickler Thema ist als GELÖST markiert

Getting started ... Alles für einen gelungenen Start.
114 Beiträge Vorherige Seite 5 von 8 (current) Nächste
114 Beiträge Vorherige Seite 5 von 8 (current) Nächste

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von black_adept (Top Expert / 3243 / 54 / 568 ) » 2. Okt 2018 13:31

ralf.wenzel hat geschrieben:Schon bei der Kapselung sind Funktionsgruppen damit „raus“, weil es keine geschützten Funktionsbausteine gibt. Jeder Funktionsbaustein ist von außen aufrufbar, somit muss der Aufrufer wissen, was er aufrufen darf und was nicht (das ist das Gegenteil von „autonom agieren“).
Ich halte Klassen und Methoden gerade wenn es um Sichtbarkeiten geht für das Mittel der Wahl - ich möchte aber darauf hinweisen, dass SAP sehr wohl Möglichkeiten bereitstellt Sichtbarkeiten von allen möglichen Objekten bereitzustellen und zwar mittels den Pakteschnittstellen (zumindest lt. Doku - ich habe das selber noch nie verwendet! ) https://help.sap.com/saphelp_nw73ehp1/h ... ameset.htm
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de


Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von black_adept (Top Expert / 3243 / 54 / 568 ) » 2. Okt 2018 13:36

ralf.wenzel hat geschrieben:Bei mir besteht eine Tabelle zum Beispiel aus dem einzigen Einzelfeld MANDT, einem Include für alle Keyfelder (Gruppenname KEY), einem weiteren DATA für die weiteren Felder, einem weiteren CREATE mit Erstellerfeldern (Name, Datum, Uhrzeit) und noch einem CHANGE (entsprechend) für die letzte Änderung.
Da verwendet wohl jemand BOPF oder hat das dort verwendete Prizinzip gut verinnerlicht...
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von DeathAndPain (Top Expert / 1052 / 122 / 230 ) » 2. Okt 2018 13:41

Dirty Assigns findest du ohne Ende im Coding der SAP. Hab ich mich gerade letzte Woche drüber geärgert, als ich nach Merkwürdigkeiten im BAL suchte.
Aber nach meinen Erfahrungen nur in richtig altem Code - oder in Code, der mit richtig altem Code umgehen muss (wenn man etwa ein altes User Exit nutzt). Es widerspricht nicht nur den Regeln von OO, sondern sehr wohl auch der Lehre strukturierter prozeduraler Programmierung.
Eine FORM-Routine ist etwas vollkommen anderes als ein Funktionsbaustein
Zunächst einmal sind beides Formen von Unterprogrammen (und Methoden wären die Dritten im Bunde). Natürlich gibt es zwischen den Dreien Unterschiede. Aber Funktionsbausteine, die ja per definitione stets global sind, sind dafür gedacht, von programmexternen Aufrufern genutzt zu werden, Formroutinen im Grundsatz nicht. "Im Grundsatz" ist hier im juristischen Sinne gemeint, also dergestalt, dass Ausnahmen die Regel bestätigen. Es ist technisch möglich, Formroutinen von völlig anderen Programmen aus aufzurufen, aber damit ist man qualitativ schon sehr dicht an einem Dirty Assign, und ein vernünftiger prozeduraler Programmierer wird das nicht machen, wenn es nicht bei der Arbeit mit Altcode unumgänglich ist.
Funktionsbaustein im Customizing festlegen? Und damit keinerlei Verwendungsnschweise mehr haben?
Das Customizing wäre ja der Verwendungsnachweis. Darin ist festgelegt, unter welchen Umständen welcher FB gerufen werden soll, und wenn Du wissen willst, wann das ausgewertet wird, dann machst Du einen WHERE-USED auf die Customizingtabelle.

Das ist also alles lösbar, nur halt mit anderen gedanklichen Ansätzen als bei OO. Wohlgemerkt behaupte ich nicht, dass das besser als OO sei, jedenfalls nicht immer. Aber es ist eine mögliche Alternative, die im Einzelfall pragmatischer und damit besser als OO sein kann. Ist halt immer die Frage, vor was für einer Aufgabenstellung man steht.
Zu den Tabellen:

Bei mir besteht eine Tabelle zum Beispiel aus dem einzigen Einzelfeld MANDT, einem Include für alle Keyfelder (Gruppenname KEY), einem weiteren DATA für die weiteren Felder, einem weiteren CREATE mit Erstellerfeldern (Name, Datum, Uhrzeit) und noch einem CHANGE (entsprechend) für die letzte Änderung.

In DATA kann man Felder zu weiteren Includes zusammenfassen, die nur/gern zusammen auftreten (Statusschema und Status).

So erhält man nicht einfach „lose“ Felder, sondern semantisch zusammenhängende Feldgruppen, die man wiederverwenden und gemeinsam ansprechen kann. Das hat mir auch bei Altkunden schon viel Arbeit erspart, wenn es etwas zu ändern gab.
Ok, jetzt habe ich es verstanden. Mir war nicht klar, dass Du meintest, Strukturen in die Tabellendefinition zu inkludieren. Der Ansatz ist mit Sicherheit gut. Davon habe ich mich in der Praxis überzeugen können, weil die Personaladministrationstabellen der SAP im HCM genau so gebaut sind (z.B. die PA0001). Mit diesen Tabellen arbeite ich viel und habe daher erkennen können, wie flexibel und nützlich dieser Ansatz ist. Da hat die SAP zur Abwechslung mal was gut gemacht.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von ralf.wenzel (Top Expert / 3416 / 149 / 220 ) » 1. Jan 2019 11:35

DeathAndPain hat geschrieben:Ich habe eine grobe Vorstellung davon, wovon die beiden reden. Was ich nicht verstehe, ist, weshalb Ralf offenbar die für diesen Zweck in OO vorgesehene Constructor-Methode durch eine selbstgebastelte Erzeugungsmethode ersetzen möchte. Wird dadurch aus OO nicht doch 00? :D Was ist der Vorteil?
Ich greife das nochmal auf, weil das Thema bei mir gerade akut ist.

Es ist oft nicht sinnvoll, einem Konstruktor „irgendwelche“ Parameter zu übergeben (die zunächst auf Gültigkeit geprüft werden müssen), sondern stattdessen für diskrete Parameter eine entsprechende Anzahl von Erzeugungsmethoden bereitzustellen.

Es ist eben nicht nur wichtig, ein Objekt aus einer Klasse zu erzeugen, sondern ein *konsistentes* Objekt. Also keineswegs 00, sondern OO, aber richtig. Der Blick, dass ein Objekt in sich konsistent sein sollte, bedingt auch, dass der Erzeuger nicht wissen muss, welche Voraussetzungen erforderlich sind für ein gültiges Objekt,

Abgesehen davon ist ein FARBKLASSE=>CREATE_SCHWARZ( ) deutlich sprechender als ein CREATE OBJECT FARBE EXPORTING farbcode = 0.

Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von SaskuAc (Specialist / 251 / 21 / 30 ) » 2. Jan 2019 12:08

ralf.wenzel hat geschrieben:
Es ist eben nicht nur wichtig, ein Objekt aus einer Klasse zu erzeugen, sondern ein *konsistentes* Objekt. Also keineswegs 00, sondern OO, aber richtig. Der Blick, dass ein Objekt in sich konsistent sein sollte, bedingt auch, dass der Erzeuger nicht wissen muss, welche Voraussetzungen erforderlich sind für ein gültiges Objekt,

Abgesehen davon ist ein FARBKLASSE=>CREATE_SCHWARZ( ) deutlich sprechender als ein CREATE OBJECT FARBE EXPORTING farbcode = 0.
Nuja, außer man gibt die ab 7.51 ( glaube ich .. kann aber auch 7.52 sein, not quite sure here ) eingeführten ENUMS her und sagt
new Farbklasse( farbcode = FARBKLASSE=>Farben-SCHWARZ ).

Wobei hier farbcode ein Element aus dem Enum "Farben" erwartet. Funktioniert änlich wie mit Klassenkonstanten, aber nur mit dem Hintergrund dass ( zumindest wurde es so angekündigt, habe leider kein System bei dem ich es ausprobieren kann ) man dann nicht umgehen kann mit ( farbcode = 0 ), sondern man muss das enum verwenden. Finde diese Funktionsweise aus anderen Sprachen extrem sinnvoll und nützlich.

Somit wäre es lesbar und sprechend und zugleich könnte man dieses Konstrukt mit den Erzeuger Methoden umgehen, falls man das nicht so mag. ( geht natürlich beides, persönlich stehe ich auch mehr auf die Erzeugermethoden, aber ich wollte hier nur die möglichkeit aufzeigen.. )

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von ralf.wenzel (Top Expert / 3416 / 149 / 220 ) » 2. Jan 2019 12:36

Und wie prüfst du, ob „schwarz“ überhaupt eine gültige Farbe ist? Im Constructor, der dann eine Ausnahme wirft, die wieder abgefangen werden muss. Darum bevorzuge ich Erzeugermethoden bei diskreten Parametern, weil es dann nur für die gültigen eine Erzeugermethode gibt.

So spart man sich das Fehlerhandling, weil Fehler gar nicht entstehen können.


Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von SaskuAc (Specialist / 251 / 21 / 30 ) » 2. Jan 2019 13:05

ralf.wenzel hat geschrieben:Und wie prüfst du, ob „schwarz“ überhaupt eine gültige Farbe ist? Im Constructor, der dann eine Ausnahme wirft, die wieder abgefangen werden muss. Darum bevorzuge ich Erzeugermethoden bei diskreten Parametern, weil es dann nur für die gültigen eine Erzeugermethode gibt.

So spart man sich das Fehlerhandling, weil Fehler gar nicht entstehen können.
Syntaxprüfung macht das automatisch.
Irgendwie so funktioniert das:

Code: Alles auswählen.

Types: enum Farben, 
   schwarz,
   rot, 
   gold. 

Code: Alles auswählen.

new Farbcode( Klasse=>Farben-lila ) " hier wird ein Syntaxfehler gewrofen 
https://blogs.sap.com/2016/10/10/abap-n ... merations/

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von DeathAndPain (Top Expert / 1052 / 122 / 230 ) » 7. Jan 2019 16:58

So hätte ich das auch erwartet. Davon abgesehen finde ich es auch viel eleganter, eine definierte Konstantenmenge zu setzen, als einen Haufen gleichartiger Methoden, die ihren Namen als impliziten Parameter missbrauchen. Im Prinzip braucht man dafür gar kein neues ENUM-Sprachelement, sondern könnte dafür auch das steinalte Element der TYPE-POOLS (Typgruppe) verwenden. Darin definiert man die erlaubten Farben und weist ihnen z.B. Integerwerte zu, die dann aber nur innerhalb der Methode eine Bedeutung haben, nach außen also gekapselt sind und dem Aufrufer nicht bekannt sein müssen. Dann bekommt er beim Aufruf mit einer nicht existenten Farbe einen Syntax Error, weil es den zugehörigen Typ nicht gibt. Das ist nicht schlechter, als wenn ich beim Aufruf mit dem Methodennamen einer nicht existenten Farbe einen Error bekomme, weil es die Methode nicht gibt. Will man das in der Klasse halten, dann geht man den üblichen Weg statischer Attribute, die sprechend die erlaubten Farben angeben und in der Klassendefinition auf einen Blick eingesehen werden können.

Das ist wie mit ABAP_TRUE und ABAP_FALSE. Da könnte man ja auch vermuten, dass es vielleicht auch ein ABAP_MAYBE gibt, aber wenn man IF antwort = ABAP_MAYBE schreibt, dann gibt es einen Syntax Error, da es diese Konstante in der Typgruppe ABAP nicht gibt. Da braucht man keine separaten Methoden COMPARE_WITH_ABAP_TRUE und COMPARE_WITH_ABAP_FALSE zu bauen. Sowas ist einfach nur Wasserkopf.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von ralf.wenzel (Top Expert / 3416 / 149 / 220 ) » 8. Jan 2019 09:45

Ich gebe zu, mein Beispiel war doof. Aber nehmen wir haben fixe Anzahl von Aufträgen ("Auftrags-Varianten", ein besseres Wort finde ich dafür nicht), die sich nicht durch Konstanten unterscheiden lassen (abgesehen davon haben wir keinen so hohen Releasestand). Oder anders ganz grob erklärt: Stellt euch eine Klasse für Bestellungen vor mit unterschiedlichen Methoden für das Erzeugen einer Normalbestellung, einer Umlagerungsbestellung, etc. Also schon wirklich betriebswirtschaftlich sehr unterschiedliche Vorgänge, die aber alle in das Konstrukt "Bestellungen" fallen.

Mit einfachen Konstanten kommt man da nicht weit und ehe ich einem Aufrufer erklären muss, wie er unter welchen Umständen den Konstruktor befüllen muss, schreibe ich ihm lieber eine Schnittstelle mit ein paar öffentlichen Methoden, die ihm das Recherchieren weitestgehend abnehmen.


ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von DeathAndPain (Top Expert / 1052 / 122 / 230 ) » 8. Jan 2019 11:25

Könnte man machen. Aber auch da wäre es durchaus eine alternative Option, dass man eine Domäne mit ein paar Festwerten ("Normalbestellung", Umlagerungsbestellung", ...) definiert und ein Datenelement dieser Domäne zum Parameter des Constructors macht. Das sollte ähnlich gut zu handhaben sein, da der Programmierer anhand der Domäne sofort sieht, welche Optionen er hat. Erst recht, wenn man den Parameter vernünftig dokumentiert.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von ralf.wenzel (Top Expert / 3416 / 149 / 220 ) » 8. Jan 2019 11:37

Es geht nicht um eine Konstante, sondern darum, ein Objekt mit weitgehend anderem Inhalt zu füllen. Klar, man könnte Konstanten definieren und in den Constructor einen CASE einbauen, aber das widerspricht der Kapselung massivst. Wenn ich dann einen neuen "Typ" bekomme, muss ich den Constructor ändern und komplett neu testen.

Da ist mir die Variante "ich mache eine neue Create-Methode" lieber, weil ich dafür bestehendes Coding nicht ändern muss.


Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von DeathAndPain (Top Expert / 1052 / 122 / 230 ) » 8. Jan 2019 14:07

Du musst den Constructor für alle Typen neu testen, wenn Du in den CASE-Block, aus dem er besteht, einen neuen "WHEN" (für einen neuen Typ) einfügst? Alles klar.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von ralf.wenzel (Top Expert / 3416 / 149 / 220 ) » 8. Jan 2019 14:17

Wenn ich ordentlich teste, dann mache ich das so. Bei trivialen Konstrukten kann man sich das schenken, aber oft sind solche Konstrukte eben nicht trivial, und dann muss man sie gescheit testen. Darum: Wenn ich eine Methode teste, teste ich sie gründlich und auch Fälle, von denen ich meine, dass ich sie nicht angefasst habe. Weil DAS sind nämlich die Stellen, wo dann Fehler hochkommen. Das Problem ist stets nicht das getestete, sondern das ungetestete Coding.

Wenn ich mein Auto in die Werkstatt bringe und die einen Reifenwechsel machen, erwarte ich auch dass der Werkstattleiter eine Probefahrt macht und nicht nur den Reifen an sich prüft.


Ralf

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von v1m4r (ForumUser / 5 / 1 / 0 ) » 8. Jan 2019 16:24

Ich finde es eine Frechheit, wie hier Neulinge behandelt werden.

Da kommt so ein alter Entwickler daher, der hier meint, alle fertig machen zu müssen.

Eine Frechheit, Ralf Wenzel sollte sich mal lieber schämen, kurz vor der Rente nen 18-22 Jährigen fertig zu machen, der sich für SAP / ABAP interessiert.

Typen wie der müssen frei von Arroganz gerne helfen, aber nicht Neulinge abschrecken. Du meinst wohl, nur weil du ein bissl OO und Designpatterns verstanden hast, dass du ein Gott bist... peinlich für die SAP Community der Ralf.

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitrag von schick (ForumUser / 32 / 3 / 7 ) » 8. Jan 2019 16:59

v1m4r hat geschrieben:Ich finde es eine Frechheit, wie hier Neulinge behandelt werden.

Da kommt so ein alter Entwickler daher, der hier meint, alle fertig machen zu müssen.

Eine Frechheit, Ralf Wenzel sollte sich mal lieber schämen, kurz vor der Rente nen 18-22 Jährigen fertig zu machen, der sich für SAP / ABAP interessiert.

Typen wie der müssen frei von Arroganz gerne helfen, aber nicht Neulinge abschrecken. Du meinst wohl, nur weil du ein bissl OO und Designpatterns verstanden hast, dass du ein Gott bist... peinlich für die SAP Community der Ralf.
Na wenn dieser Beitrag nicht mal deutlich peinlicher ist als alle anderen in diesem Thread... :?

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


Vorherige Seite 5 von 8 (current) Nächste

Aktuelle Forenbeiträge

Langtext zur Exception
vor 56 Minuten von a-dead-trousers 11 / 96
Welche Entwicklertools?
vor 18 Stunden von LostDarkness 2 / 922
Werksspezifische Konfiguration kopieren
vor 19 Stunden von eleve 2 / 48
Removal of left space - next to a docking container
vor 19 Stunden von Haemma83 16 / 115

Unbeantwortete Forenbeiträge

BAPI_PO_CREATE1 und Einkaufsinfosatz
vor 3 Tagen von SweetRuedi 1 / 81
WCOCO: Gruppe für Betragsfelder 0S01
vor 5 Tagen von SAP_ENTWICKLER 1 / 52
CAS-Nr.: Chemical Abstracs Service
vor einer Woche von SAP_ENTWICKLER 1 / 92
Interaktives Skript, Rolle IC-Manager
vor 3 Wochen von erubadhron86 1 / 129