Einführung in ABAP Objects
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo,
welches Buch könnt Ihr für jemand der noch nie objektorientiert porgrammiert hat für den entsprechenden Einstieg in ABAP empfehlen.
- Enjoy SAPControls von dpunkt-verlag
- ABAP Objects von sap-press
- Anwendungsentwicklung mit ABAP-Objects von sap-press
Oder gibt es irgendwo im Netz ein nachvollziehbares Tutorial mit gescheitem Beispiel.
Die beiden Bücher von sap-press sind für mich in vielen Punkten nicht richtig nachvollziehbar. Deshalb wäre ein echtes Einsteigerbuch wirklich gut.
Vielleicht weiß ja jemand noch ein anderes, wie die typischen sap-press bücher....
Es sollte aber kein Einsteigerbuch für "prodzedurales" ABAP sein.
Oder - wie habt Ihr Euch das beigebracht. Schulungen bei SAP? Kollegen? Habt Ihr vorher schon eine andere objektorientierte Programmiersprache gekannt?
Oder - entwickelt nur SAP objektorientiert?
Vielen Dank für Infos
welches Buch könnt Ihr für jemand der noch nie objektorientiert porgrammiert hat für den entsprechenden Einstieg in ABAP empfehlen.
- Enjoy SAPControls von dpunkt-verlag
- ABAP Objects von sap-press
- Anwendungsentwicklung mit ABAP-Objects von sap-press
Oder gibt es irgendwo im Netz ein nachvollziehbares Tutorial mit gescheitem Beispiel.
Die beiden Bücher von sap-press sind für mich in vielen Punkten nicht richtig nachvollziehbar. Deshalb wäre ein echtes Einsteigerbuch wirklich gut.
Vielleicht weiß ja jemand noch ein anderes, wie die typischen sap-press bücher....
Es sollte aber kein Einsteigerbuch für "prodzedurales" ABAP sein.
Oder - wie habt Ihr Euch das beigebracht. Schulungen bei SAP? Kollegen? Habt Ihr vorher schon eine andere objektorientierte Programmiersprache gekannt?
Oder - entwickelt nur SAP objektorientiert?
Vielen Dank für Infos
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
Ich persoenlich finde 'ABAP Objects von sap-press' recht gut und verstaendlich mit genuegend Beispielen. Der Rest war prinzipiell learning and doing. Benutzt habe ich auch fleissig die Transaktion ABAPDOCU und mir die OO-Beispiele dort angesehen.
Allerdings muss ich dazusagen, dass ich - bevor ich ABAP-OO programmiert habe - schon einige Jahre Erfahrung mit C++ und Java hatte. Insofern war der ABAP-OO Einstieg keine grosse Sache.
Ansonsten wuerde ich zum Einstieg eine Schulung empfehlen - finde aber dennoch das obige Buch sehr gut als Referenz.
Hoffe das hilft. Andere Meinungen Tipps willkommen
Gruss,
Steff
Ich persoenlich finde 'ABAP Objects von sap-press' recht gut und verstaendlich mit genuegend Beispielen. Der Rest war prinzipiell learning and doing. Benutzt habe ich auch fleissig die Transaktion ABAPDOCU und mir die OO-Beispiele dort angesehen.
Allerdings muss ich dazusagen, dass ich - bevor ich ABAP-OO programmiert habe - schon einige Jahre Erfahrung mit C++ und Java hatte. Insofern war der ABAP-OO Einstieg keine grosse Sache.
Ansonsten wuerde ich zum Einstieg eine Schulung empfehlen - finde aber dennoch das obige Buch sehr gut als Referenz.
Hoffe das hilft. Andere Meinungen Tipps willkommen
Gruss,
Steff
Servus,
ich kann nur das ABAP Objects empfehlen:
ABAP Objects bzw.: ABAP Objects in der 2006er Version
Wobei mir das erste am meisten geholfen hat. Grundsätzlich ist das so ne Sache mit der Objektorientierung und ABAP
Ich habe OO über Java gelernt, dann prozedural ABAP und dann ABAP OO. Was mir damals extrem geholen hat war eine UML Schulung. Dort haben wir Programm erst designed und dann umgesetzt und zwar in dem OO-Denkmodell.
Sobald man das einmal sauber umgesetzt und verstanden hat ist die programmierung ein leichtes
was genau möchtest du denn programmieren? 'nur' die OO-ALV etc, oder tatsächlich eine gesamte Transaktion.
Gruß Aze
ps.: versuche mich gerade an ABAP - Next Generation
ich kann nur das ABAP Objects empfehlen:
ABAP Objects bzw.: ABAP Objects in der 2006er Version
Wobei mir das erste am meisten geholfen hat. Grundsätzlich ist das so ne Sache mit der Objektorientierung und ABAP
Ich habe OO über Java gelernt, dann prozedural ABAP und dann ABAP OO. Was mir damals extrem geholen hat war eine UML Schulung. Dort haben wir Programm erst designed und dann umgesetzt und zwar in dem OO-Denkmodell.
Sobald man das einmal sauber umgesetzt und verstanden hat ist die programmierung ein leichtes
was genau möchtest du denn programmieren? 'nur' die OO-ALV etc, oder tatsächlich eine gesamte Transaktion.
Gruß Aze
ps.: versuche mich gerade an ABAP - Next Generation
Ich programmiere schon einige Zeit ABAP.
Prozedural ist das auch kein Problem.
Wirklich zum Progrmamieren ganzer Anwendungen kommt man ja relativ wenig und wenn - dann ist es ein report und der ist wahrscheinlich mit "alten" Mitteln meist einfacher zu realisieren.
Aber ich möchte mich trotzdem mit OO-Programmierung beschäftigen - was immer da auch kommt würde ich vielleicht dann einfach mal objektorientiert probieren.
Allerdings sehe ich das ganze einfach als viel zu kompliziert an, was zum teil sicherlich am Verständnis und auch der noch nicht eingeprägten "Notation" liegt.
Wahrscheinlich werde ich die Bücher irgendwann nochmals von vorne lesen...
Aber viele von Euch kannten OO ja schon von anderen Programmiersprachen - und ich glaube das es dort einfacher ist und auch die Entwicklungsumgebung viel mehr unterstützt als dies in ABAP der Fall ist ????
Ist OO in ABAP vieeeeeel schlechter als in anderen Programmiersprachen oder habe ich als nicht andere Programmiersprachenkenner einfach nur dieses Vorurteil?
Prozedural ist das auch kein Problem.
Wirklich zum Progrmamieren ganzer Anwendungen kommt man ja relativ wenig und wenn - dann ist es ein report und der ist wahrscheinlich mit "alten" Mitteln meist einfacher zu realisieren.
Aber ich möchte mich trotzdem mit OO-Programmierung beschäftigen - was immer da auch kommt würde ich vielleicht dann einfach mal objektorientiert probieren.
Allerdings sehe ich das ganze einfach als viel zu kompliziert an, was zum teil sicherlich am Verständnis und auch der noch nicht eingeprägten "Notation" liegt.
Wahrscheinlich werde ich die Bücher irgendwann nochmals von vorne lesen...
Aber viele von Euch kannten OO ja schon von anderen Programmiersprachen - und ich glaube das es dort einfacher ist und auch die Entwicklungsumgebung viel mehr unterstützt als dies in ABAP der Fall ist ????
Ist OO in ABAP vieeeeeel schlechter als in anderen Programmiersprachen oder habe ich als nicht andere Programmiersprachenkenner einfach nur dieses Vorurteil?
Hallo,
naja, etwas OO-Verständnis sollte man schon haben.
Mir reicht es, wenn ich mir vorstelle, es gibt ein Objekt mit "Anfasser". Ich binde den "Drachen" ans Geländer (OO-Variable) kann "Briefchen" raufschicken (Methode aufrufen). Das Ergebnis kommt wieder runter(Oder es wurde etwas anderes gemacht ...).
Den ganzen Vererbungskram, oder Klassenlokal, Klassenglobal, Objektbezogen oder nicht, kann man erstmal übergehen.
Im Prinzip ist ABAP-OO nur die Fortführung dessen, was mit FORMS und Funktionsbausteinen schon länger gemacht wurde. Funktionen, die mehrfach gebraucht werden, sind in sich abgeschlossen programmiert und wiederverwendbar.
ABAP-OO kapselt die Module noch restriktiver und zwingt so, zu SAUBERER Programmierung. Hinter den Kulissen läuft ganz normales ABAP-Coding.
Nein, es gibt keine Aufgabe, die mit herkömmlichem prozeduralem Code besser zu lösen wäre.
(Ab und zu fällt man auf den Gedanken rein. Dann büßt man es aber recht schnell ...)
Ich löse schon seit längerem alle Aufgaben nur noch mit Abap-OO. Tatsächlich benötigt man als Einstieg oft noch eine Transaktion und ein herkömmliches Programm, um Parameter anzugeben. Wenn nötig, nutze ich zum Aufruf oder zur Anzeige von Dynpros einen Funktionsbaustein.
Aber sobald es geht, erzeuge ich ein Objekt, und verzweige dorthin.
Viele Leute lassen sich abschrecken, weil beim Programmieren mit ABAP-OO viele Dinge im DDIC eingetragen werden müssen.
Zur Nutzung von Tabellen als Parameter sind z.B. Tabellentypen notwendig etc.
Auch das Konfigurieren der Klassen geschieht per Menü.
Ich empfinde das als Erleichterung gegenüber dem Gewurschtel mit DATA und TYPES, bevor das Programm beginnt ...
Klassen kann man wunderschön im Dialog testen.
Gruß
babap
P.S. einfach mal ausprobieren.
naja, etwas OO-Verständnis sollte man schon haben.
Mir reicht es, wenn ich mir vorstelle, es gibt ein Objekt mit "Anfasser". Ich binde den "Drachen" ans Geländer (OO-Variable) kann "Briefchen" raufschicken (Methode aufrufen). Das Ergebnis kommt wieder runter(Oder es wurde etwas anderes gemacht ...).
Den ganzen Vererbungskram, oder Klassenlokal, Klassenglobal, Objektbezogen oder nicht, kann man erstmal übergehen.
Im Prinzip ist ABAP-OO nur die Fortführung dessen, was mit FORMS und Funktionsbausteinen schon länger gemacht wurde. Funktionen, die mehrfach gebraucht werden, sind in sich abgeschlossen programmiert und wiederverwendbar.
ABAP-OO kapselt die Module noch restriktiver und zwingt so, zu SAUBERER Programmierung. Hinter den Kulissen läuft ganz normales ABAP-Coding.
Nein, es gibt keine Aufgabe, die mit herkömmlichem prozeduralem Code besser zu lösen wäre.
(Ab und zu fällt man auf den Gedanken rein. Dann büßt man es aber recht schnell ...)
Ich löse schon seit längerem alle Aufgaben nur noch mit Abap-OO. Tatsächlich benötigt man als Einstieg oft noch eine Transaktion und ein herkömmliches Programm, um Parameter anzugeben. Wenn nötig, nutze ich zum Aufruf oder zur Anzeige von Dynpros einen Funktionsbaustein.
Aber sobald es geht, erzeuge ich ein Objekt, und verzweige dorthin.
Viele Leute lassen sich abschrecken, weil beim Programmieren mit ABAP-OO viele Dinge im DDIC eingetragen werden müssen.
Zur Nutzung von Tabellen als Parameter sind z.B. Tabellentypen notwendig etc.
Auch das Konfigurieren der Klassen geschieht per Menü.
Ich empfinde das als Erleichterung gegenüber dem Gewurschtel mit DATA und TYPES, bevor das Programm beginnt ...
Klassen kann man wunderschön im Dialog testen.
Gruß
babap
P.S. einfach mal ausprobieren.
seit ca. 6.40 kann man auch PUBLIC komplexe Typen (Tabellentypen, strukturierte Typen, etc.) anlegen, so dass es nicht mehr zwangsweise notwendig ist, DDIC-Definition anzulegen.babap hat geschrieben:...
Viele Leute lassen sich abschrecken, weil beim Programmieren mit ABAP-OO viele Dinge im DDIC eingetragen werden müssen.
Zur Nutzung von Tabellen als Parameter sind z.B. Tabellentypen notwendig etc.
Auch das Konfigurieren der Klassen geschieht per Menü.
Ich empfinde das als Erleichterung gegenüber dem Gewurschtel mit DATA und TYPES, bevor das Programm beginnt ...
Nachteil: siehe unten...
Gilt leider nicht für Klassen, die komplexe Typen PUBLIC definieren und z.B. in Methodenschnittstellen benutzt. Damit kommt die Testumgebung für Klassen nicht zurecht und führt zum Dump.babap hat geschrieben:Klassen kann man wunderschön im Dialog testen.
Gruß
babap
P.S. einfach mal ausprobieren.
PS:
ich stehe auf dem Standpunkt, dass man nicht immer DDIC-Typen anlegen muss, wenn man sich nur in einer Anwendung bewegt.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Hallo,
da hier "Anfänger" nach einer Methode suchen, schnell mit ABAP-OO vertraut zu werden, kann ich nur eine Methode und Vorgehensweise vorschlagen, die immer funktioniert, und auch einfach zu bedienen und zu testen ist. (Und die ich anwende und verstehe ...)
Natürlich muß man dann auch die anderen Konstrukte wie Pakete oder "Unterpakete" benutzen, damit man "das ganze Zeug" was man dort abgelegt hat geordnet wiederfindet.
Gerade bei klassenlokalen Typen bzw. klassenglobalen Typen ist man sehr schnell am Ende, wenn man verschiedene Klassen hat, die die gleichen Typen verwenden bzw. übergeben wollen ...
Und eine "Anwendung" beschränkt sich nun mal nicht auf bloß eine Klasse. Da hat man ruck zuck den ganzen Zoo von Programmen über Funktionsbausteine bis Klassen am Wickel. Und da ist es wirklich übersichtlicher, das Ganze zu strukturieren und im DDIC zu definieren.
Gruß
babap
da hier "Anfänger" nach einer Methode suchen, schnell mit ABAP-OO vertraut zu werden, kann ich nur eine Methode und Vorgehensweise vorschlagen, die immer funktioniert, und auch einfach zu bedienen und zu testen ist. (Und die ich anwende und verstehe ...)
Wie ich bereits öfter woanders geschrieben habe, sehe ich das komplett anders. Es geht nicht um "anlegen müssen", sondern im DDIC anlegen bzw. anlegen dürfen, weil es viel praktischer ist und das ganze Prozedere sehr erleichtert.ereglam hat geschrieben:PS:
ich stehe auf dem Standpunkt, dass man nicht immer DDIC-Typen anlegen muss, wenn man sich nur in einer Anwendung bewegt.
Natürlich muß man dann auch die anderen Konstrukte wie Pakete oder "Unterpakete" benutzen, damit man "das ganze Zeug" was man dort abgelegt hat geordnet wiederfindet.
Gerade bei klassenlokalen Typen bzw. klassenglobalen Typen ist man sehr schnell am Ende, wenn man verschiedene Klassen hat, die die gleichen Typen verwenden bzw. übergeben wollen ...
Und eine "Anwendung" beschränkt sich nun mal nicht auf bloß eine Klasse. Da hat man ruck zuck den ganzen Zoo von Programmen über Funktionsbausteine bis Klassen am Wickel. Und da ist es wirklich übersichtlicher, das Ganze zu strukturieren und im DDIC zu definieren.
Gruß
babap
dem habe ich m.W. auch nicht widersprochen. Es sollte auch nur ein Hinweis sein, dass man ab 6.40 etwas machen kann, was vorher nicht möglich war.babap hat geschrieben:Hallo,
da hier "Anfänger" nach einer Methode suchen, schnell mit ABAP-OO vertraut zu werden, kann ich nur eine Methode und Vorgehensweise vorschlagen, die immer funktioniert, und auch einfach zu bedienen und zu testen ist. (Und die ich anwende und verstehe ...)
Wenn ich mir so ansehe, was alles im DDIC worden ist und keiner genau weiß, wer es alles benutzt, finde ich die Möglichkeit, in einer Klasse auch Typen, etc. zu definieren recht gut, um mal den Zusammenhang zu erhalten. Dann kann man auch besser abschätzen, ob etwas für die eigenen Zwecke sinnvoll erscheint.babap hat geschrieben:Wie ich bereits öfter woanders geschrieben habe, sehe ich das komplett anders. Es geht nicht um "anlegen müssen", sondern im DDIC anlegen bzw. anlegen dürfen, weil es viel praktischer ist und das ganze Prozedere sehr erleichtert.ereglam hat geschrieben:PS:
ich stehe auf dem Standpunkt, dass man nicht immer DDIC-Typen anlegen muss, wenn man sich nur in einer Anwendung bewegt.
Natürlich muß man dann auch die anderen Konstrukte wie Pakete oder "Unterpakete" benutzen, damit man "das ganze Zeug" was man dort abgelegt hat geordnet wiederfindet.
Gerade bei klassenlokalen Typen bzw. klassenglobalen Typen ist man sehr schnell am Ende, wenn man verschiedene Klassen hat, die die gleichen Typen verwenden bzw. übergeben wollen ...
Und eine "Anwendung" beschränkt sich nun mal nicht auf bloß eine Klasse. Da hat man ruck zuck den ganzen Zoo von Programmen über Funktionsbausteine bis Klassen am Wickel. Und da ist es wirklich übersichtlicher, das Ganze zu strukturieren und im DDIC zu definieren.
Gruß
babap
Das bekommt man zwar auch in gewisser Weise auch durch einen Verwendungsnachweis, aber eben auch nicht wirklich eindeutig.
PS:
ich benutze auch gerne TYPE-POOLS, weil auch dort ein gewisser Zusammenhang implizit zur Verfügung gestellt wird.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Hallo jspranz,
ich habe im Studium OO durch C++ und Java gelernt. Die ABAP Objects sind meistens noch sehr an das alte ABAP angelehnt und wenn du wirklich OO programmieren willst, solltest du einen großen Bogen um das alte Zeug machen.
Viele Dinge bei ABAP Objects machen für mich keinen Sinn und zeigen, dass es immer noch nicht objektorientiert, sondern oft nur runterscripten ist.
Es geht immer noch nicht immer um die Objekte, sondern um das Zerteilen/Zerstückeln des Quellcodes in Includes und um neue Namenskonventionen, die nach OO klingen, aber nur Schall und Rauch sind.
Ich würde dir ein Buch empfehlen (direkt einen Titel habe ich leider nicht), das UML verwendet. An UML kann man die Objektorientierung sehr gut lernen. Beziehungen Oberklasse-Unterklasse, Vererbung. Privat-Public. Wenn du das Prinzip einmal richtig verstanden hast, wird deine Programmierung von sich aus schon sehr schön und gut lesbar sein.
Ich hatte schon einige ABAP Objects-Schulungen und immer, wenn ich gerade drin sitze und dem Programmierer zusehe, kann ich ihm folgen, doch 3 Tage später erscheint mir vieles unlogisch und nicht mehr nachvollziehbar. Am besten, du machst dir ein kleines ABAP Objects Beispiel und versuchst die Ansätze der OO zu beachten.
In vielen Firmen, die kein SAP verwenden, wird der Model-View-Controller - Ansatz bei OO eingesetzt. Das bedeutet: eine Klasse (in SAP heißt Klasse = Include) für das Model - die Datenbeschaffung. Eine Klasse für die View - die Datenanzeige. Und die dritte Klasse Controller - für die Logik (Button-Ereignisse, etc.)
Natürlich kann die Model- oder die View-Klasse von mehreren anderen Klassen erben oder sie includen.
Die ABAP-Entiwckler, mit denen ich zusammen arbeite, schaffen den Umstieg leider nicht. Sie verwenden seit 1-2 Jahren zwar unzählige Includes, aber programmieren nicht objektorientiert. Dann hätte man auch weiter Funktionsbausteine und BAPIs verwenden können.
Ich wünsche dir viel Erfolg,
C.W.
ich habe im Studium OO durch C++ und Java gelernt. Die ABAP Objects sind meistens noch sehr an das alte ABAP angelehnt und wenn du wirklich OO programmieren willst, solltest du einen großen Bogen um das alte Zeug machen.
Viele Dinge bei ABAP Objects machen für mich keinen Sinn und zeigen, dass es immer noch nicht objektorientiert, sondern oft nur runterscripten ist.
Es geht immer noch nicht immer um die Objekte, sondern um das Zerteilen/Zerstückeln des Quellcodes in Includes und um neue Namenskonventionen, die nach OO klingen, aber nur Schall und Rauch sind.
Ich würde dir ein Buch empfehlen (direkt einen Titel habe ich leider nicht), das UML verwendet. An UML kann man die Objektorientierung sehr gut lernen. Beziehungen Oberklasse-Unterklasse, Vererbung. Privat-Public. Wenn du das Prinzip einmal richtig verstanden hast, wird deine Programmierung von sich aus schon sehr schön und gut lesbar sein.
Ich hatte schon einige ABAP Objects-Schulungen und immer, wenn ich gerade drin sitze und dem Programmierer zusehe, kann ich ihm folgen, doch 3 Tage später erscheint mir vieles unlogisch und nicht mehr nachvollziehbar. Am besten, du machst dir ein kleines ABAP Objects Beispiel und versuchst die Ansätze der OO zu beachten.
In vielen Firmen, die kein SAP verwenden, wird der Model-View-Controller - Ansatz bei OO eingesetzt. Das bedeutet: eine Klasse (in SAP heißt Klasse = Include) für das Model - die Datenbeschaffung. Eine Klasse für die View - die Datenanzeige. Und die dritte Klasse Controller - für die Logik (Button-Ereignisse, etc.)
Natürlich kann die Model- oder die View-Klasse von mehreren anderen Klassen erben oder sie includen.
Die ABAP-Entiwckler, mit denen ich zusammen arbeite, schaffen den Umstieg leider nicht. Sie verwenden seit 1-2 Jahren zwar unzählige Includes, aber programmieren nicht objektorientiert. Dann hätte man auch weiter Funktionsbausteine und BAPIs verwenden können.
Ich wünsche dir viel Erfolg,
C.W.
Hallo,
so negativ sollte man Abap-OO nicht beurteilen.
Klar, ABAP-OO ist ein "Häubchen" auf dem Abap-Laufzeitsystem. Aber was hinter den Kulissen läuft ist ja egal. (Auch die anderen Compiler und Interpreter wurschteln ganz schön vor sich hin.)
Ein weiteres ist, wie mit ABAP-OO umgegangen wird.
Leider ist im SAP-Umfeld noch das ganze Coding weitgehen "alt".
Alle neuen Sachen werden konsequent in Abap-OO entwickelt. Aber alte Programme auf OO umzustellen ist sehr schwierig.
NEIN: Klasse heißt nicht Include bei SAP!
Das was Du da berichtest schein ein Anwendungsfall zu sein (oder Du meinst den Persistenzdienst oder was anders).
Die ganze INCLUDiererei ist bloß Tradition. Das ist eine rudimentäre Methode, Quelltext wiederzuverwenden. Man muß wissen was es macht und wie es funktioniert, damit man alte Anwendungen "lesen" kann.
Und da sind Incudes noch das harmlosesete. Dynpros, Modulpools, zur Laufzeit modifizierte Listen und Bildschirme etc.. Da gibt es mannigfaltige Fußangeln und Sauer**** ohne Ende.
ABAP-OO an sich ist sehr schön zu programmieren.
Und wenn man als SAP-Programmierer wirklich will, kann man damit die OO-Welt entdecken.
Viel Erfolg bei der Weiterbildung!
Viele Grüße
babap
so negativ sollte man Abap-OO nicht beurteilen.
Klar, ABAP-OO ist ein "Häubchen" auf dem Abap-Laufzeitsystem. Aber was hinter den Kulissen läuft ist ja egal. (Auch die anderen Compiler und Interpreter wurschteln ganz schön vor sich hin.)
Ein weiteres ist, wie mit ABAP-OO umgegangen wird.
Leider ist im SAP-Umfeld noch das ganze Coding weitgehen "alt".
Alle neuen Sachen werden konsequent in Abap-OO entwickelt. Aber alte Programme auf OO umzustellen ist sehr schwierig.
NEIN: Klasse heißt nicht Include bei SAP!
Das was Du da berichtest schein ein Anwendungsfall zu sein (oder Du meinst den Persistenzdienst oder was anders).
Die ganze INCLUDiererei ist bloß Tradition. Das ist eine rudimentäre Methode, Quelltext wiederzuverwenden. Man muß wissen was es macht und wie es funktioniert, damit man alte Anwendungen "lesen" kann.
Und da sind Incudes noch das harmlosesete. Dynpros, Modulpools, zur Laufzeit modifizierte Listen und Bildschirme etc.. Da gibt es mannigfaltige Fußangeln und Sauer**** ohne Ende.
ABAP-OO an sich ist sehr schön zu programmieren.
Und wenn man als SAP-Programmierer wirklich will, kann man damit die OO-Welt entdecken.
Viel Erfolg bei der Weiterbildung!
Viele Grüße
babap
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Naja, mehr als die SAP, aber das ist nicht so schwierig. Ich hab ne ziemliche Kappe wenn ich an ABAP OO denke. Keiner (von den Kunden) weiß was das ist, alle wollen es haben und die Mehraufwände in der Entwicklung nicht bezahlen (weil sie denken, das sei billiger, weil neuer und moderner).babap hat geschrieben:naja, etwas OO-Verständnis sollte man schon haben.
Dann guck dir mal das Coding von der SAP an, wie herrlich vermischt Prozedurales mit OO man da findet. Da basteln die große Klassenkonstrukte und springen dann per PERFORM raus und machen prozedural weiter. Sowas ist alter Wein in alten Schläuchen, die ein bisschen aufgepeppt sind.babap hat geschrieben:Im Prinzip ist ABAP-OO nur die Fortführung dessen, was mit FORMS und Funktionsbausteinen schon länger gemacht wurde. Funktionen, die mehrfach gebraucht werden, sind in sich abgeschlossen programmiert und wiederverwendbar.
Das Problem ist eher, dass hinter den Kulissen ganz normale Programmierer sitzen. Wenn ich wirklich objektorientiert anfange zu programmieren, sind die ersten die mir das Projekt um die Ohren hauen, die Inhouse-Entwickler des Kunden.babap hat geschrieben:ABAP-OO kapselt die Module noch restriktiver und zwingt so, zu SAUBERER Programmierung. Hinter den Kulissen läuft ganz normales ABAP-Coding.
Richtig.babap hat geschrieben:Nein, es gibt keine Aufgabe, die mit herkömmlichem prozeduralem Code besser zu lösen wäre.
(Ab und zu fällt man auf den Gedanken rein. Dann büßt man es aber recht schnell ...)
Da gehts doch schon los. Man braucht prozedurales Coding zum Einstieg. Ich habe mal einen einfachen Vergleich gemacht - nicht repräsentativ natürlich. Ich habe ein x-beliebige und sehr einfache Reportanforderung (Selektieren, zusammenführen, Ausgabe als ALV-Grid) genommen und einmal prozedural und einmal in OO umgesetzt. Das OO-Coding war erheblich aufgeblasener, der Aufwand 50% höher (und das war eine Aufgabe, wo nichts zu planen war - versuch doch einem x-beliebigen Programmierer mal zu erklären was Design Patterns sind). Und: Das prozedurale Coding konnte ich so zusammenfassen, dass ich es in eine Datei runterladen konnte.babap hat geschrieben:Ich löse schon seit längerem alle Aufgaben nur noch mit Abap-OO. Tatsächlich benötigt man als Einstieg oft noch eine Transaktion und ein herkömmliches Programm, um Parameter anzugeben. Wenn nötig, nutze ich zum Aufruf oder zur Anzeige von Dynpros einen Funktionsbaustein.
DAS ist Wiederverwendbarkeit -- ich habe seit dieser Zeit eine prozedurale ALV-Listen-Vorlage (ca. 500 Codingzeilen für fast alle Eventualitäten gerüstet, gut dokumentiert). Ca. 50 mal benutzt und sehr beliebt bei Kunden, weil dann nämlich alle Listencodings sehr ähnlich aussehen.
Ich nehme OO wenn ich dazu gezwungen werde. In den meisten Fällen reicht eine einfache Aufwandschätzung in zwei Versionen, um dem Kunden das auszureden. Ich programmiere auf des Kunden Wunsch in 80 Prozent aller Fälle ganz einfache Funktionsgruppen (für alles andere) oder Reports für Listen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das ist gar nicht so schwierig - die SAP müsste allerdings Völkerstämme von Programmierern anstellen um das zu bewerkstelligen. Das will keiner bezahlen.babap hat geschrieben:Leider ist im SAP-Umfeld noch das ganze Coding weitgehen "alt".
Alle neuen Sachen werden konsequent in Abap-OO entwickelt. Aber alte Programme auf OO umzustellen ist sehr schwierig.
Ich habe noch Ende der 90er die Zahlungsbegleitliste erweitert - das war pures R/2-Coding. Inzwischen ist das Teil komplett neu geschrieben, wenn ich mich nicht irre.
Funktionierendes Coding auf OO umzustellen mit komplett neuem Bugfixing etc ist auch rein betriebswirtschaftlich die Qualifikation zur Gummizelle.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
3866
Views
Views
6
Antw.
Antw.
5790
Views
Views
4
Antw.
Antw.
3016
Views
Views
2
Antw.
Antw.
2094
Views
Views
5
Antw.
Antw.
3873
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
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.