Gehaltsvorstellungen SAP ABAP-Entwickler
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
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.htmralf.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“).
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Da verwendet wohl jemand BOPF oder hat das dort verwendete Prizinzip gut verinnerlicht...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.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.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.
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.Eine FORM-Routine ist etwas vollkommen anderes als ein Funktionsbaustein
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.Funktionsbaustein im Customizing festlegen? Und damit keinerlei Verwendungsnschweise mehr haben?
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.
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.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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich greife das nochmal auf, weil das Thema bei mir gerade akut ist.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?Was ist der Vorteil?
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 • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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 sagtralf.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.
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.. )
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
So spart man sich das Fehlerhandling, weil Fehler gar nicht entstehen können.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Syntaxprüfung macht das automatisch.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.
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
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.
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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
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 • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
Da ist mir die Variante "ich mache eine neue Create-Methode" lieber, weil ich dafür bestehendes Coding nicht ändern muss.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
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.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
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
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 • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
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.
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...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.
Folgende Benutzer bedankten sich beim Autor schick für den Beitrag:
DeathAndPain
Vergleichbare Themen
1
Antw.
Antw.
1815
Views
Views
26
Antw.
Antw.
6967
Views
Views
Selbständigkeit als ABAP-Entwickler
von Bright4.5 » 15.08.2020 14:31 • Verfasst in ABAP® für Anfänger
von Bright4.5 » 15.08.2020 14:31 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
1842
Views
Views
4
Antw.
Antw.
1313
Views
Views
Nächsten Schritte als ABAP Entwickler
von retsch » 16.05.2023 07:07 • Verfasst in ABAP® für Anfänger
von retsch » 16.05.2023 07:07 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2265
Views
Views
ABAP Entwickler (m/w) im Großraum Köln / Bonn gesucht
von jobmanager24 Bonn » 15.12.2011 11:32 • Verfasst in SAP - Allgemeines
von jobmanager24 Bonn » 15.12.2011 11:32 • Verfasst in SAP - Allgemeines
Frage die ABAP Experten
Über diesen Beitrag
- Guest12345
- ralf.wenzel
- deejey
- zzcpak
- ewx
- nickname8
- DeathAndPain
- black_adept
- SaskuAc
- v1m4r
- schick
- Romaniac
- 4byte
- Daniel
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.