gelöst Gehaltsvorstellungen SAP ABAP-Entwickler


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon black_adept » 02.10.2018, 12: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/helpdata/en/ea/c05d92f01011d3964000a0c94260a5/frameset.htm
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3139
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 534 mal
Ich bin: Freiberufler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon black_adept » 02.10.2018, 12: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
black_adept
Top Expert
 
Beiträge: 3139
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 534 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 02.10.2018, 12: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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 01.01.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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon SaskuAc » 02.01.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.. )
SaskuAc
Specialist
 
Beiträge: 215
Registriert: 01.06.2015, 10:16
Dank erhalten: 21 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 02.01.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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon SaskuAc » 02.01.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/
SaskuAc
Specialist
 
Beiträge: 215
Registriert: 01.06.2015, 10:16
Dank erhalten: 21 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 07.01.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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 08.01.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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 08.01.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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 08.01.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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon DeathAndPain » 08.01.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.
DeathAndPain
Expert
 
Beiträge: 849
Registriert: 05.05.2006, 10:14
Dank erhalten: 197 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon ralf.wenzel » 08.01.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
ralf.wenzel
Top Expert
 
Beiträge: 3306
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 201 mal
Ich bin: Freiberufler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon v1m4r » 08.01.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.
v1m4r
ForumUser
 
Beiträge: 5
Registriert: 18.10.2018, 14:18
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Gehaltsvorstellungen SAP ABAP-Entwickler

Beitragvon schick » 08.01.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... :?

Für diese Nachricht hat schick einen Dank bekommen :
DeathAndPain
schick
ForumUser
 
Beiträge: 21
Registriert: 16.02.2018, 08:22
Dank erhalten: 4 mal
Ich bin: Berater/in

VorherigeNächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
Umrechnung Stück in KG
vor 4 Minuten von wreichelt 2 Antw.
gelöst Sel.Screen in Subscreen - VA06
vor 16 Stunden von bapimueller 2 Antw.
gelöst Prüfen Konfiguration Kundenauftrag gene Type
vor 22 Stunden von mfromg 0 Antw.
Auswertung Orders erhalt per Mail oder FAX oder beides
vor 16 Stunden von ewx 2 Antw.
SAP und Gamification
Gestern von ewx 1 Antw.

  Ähnliche Beiträge beta
Keine Beiträge gefunden - versuche es mit der erweiterten Suche.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]