Umstellung ABAP auf ABAP Objects
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo zusammen.
Mal im voraus: Ich bin ABAP-Programmierer, habe aber keine Ahnung von ABAP Objects. Mein chef brachte nun den vorschlag, die Programmierung von ABAP langsam aber sicher auf ABAP Objects umzustellen. Nun meine Frage an euch:
Ist es sinnvoll auf objektorientierte Programmierung umzusteigen? Vorteile / Nachteile? Welche Probleme könnte es geben? Hat jemand von euch vielleicht so einen Umstellung schon mal durchgemacht?
Ich bitte um viele Erfahrungsberichte und Meinungen!
Danke schon mal!
Andi
Mal im voraus: Ich bin ABAP-Programmierer, habe aber keine Ahnung von ABAP Objects. Mein chef brachte nun den vorschlag, die Programmierung von ABAP langsam aber sicher auf ABAP Objects umzustellen. Nun meine Frage an euch:
Ist es sinnvoll auf objektorientierte Programmierung umzusteigen? Vorteile / Nachteile? Welche Probleme könnte es geben? Hat jemand von euch vielleicht so einen Umstellung schon mal durchgemacht?
Ich bitte um viele Erfahrungsberichte und Meinungen!
Danke schon mal!
Andi
Hauptsoch: HAUPTSOCH!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi,
grundsaetzlich: 'Never touch a running system'. Warum umstellen, wenn alles soweit funktioniert?!
Die offensichtlichen Vorteile der objektorientierten Programmierung sind sicherlich die Wiederverwendbarkeit, die bessere Wartbarkeit, modellierungsgetriebener Ansatz, etc.
Objektorientiertes Programmieren birgt die Gefahr, dass sich bei schlechtem Design sowie beim Übertreiben (exzessives Vererben, zu sehr spezialisierte Subklassen) die Vorteile in Nachteile wandeln, die Software wird schlechter wartbar, Wiederverwendung wird erschwert/unmoeglich. Ausserdem kann sich objektorientiertes Progammieren nachteilig auf die Performance auswirken (z.B.: dynamic binding).
Wenn also Eure Programme momentan leicht wartbar sind, alles funktioniert, performant ist und im Prinzip daher kein Bedarf besteht, dann wuerde ich von einer Umstellung absehen. Zumindest was die bestehenden Programme anbelangt. Bei Neuentwicklung kann man sich grundsaetzlich ueberlegen, kuenftig objektorientiert zu programmieren um die Vorteile zu nutzen.
... just my 2 cents.
Gruss,
Steff
grundsaetzlich: 'Never touch a running system'. Warum umstellen, wenn alles soweit funktioniert?!
Die offensichtlichen Vorteile der objektorientierten Programmierung sind sicherlich die Wiederverwendbarkeit, die bessere Wartbarkeit, modellierungsgetriebener Ansatz, etc.
Objektorientiertes Programmieren birgt die Gefahr, dass sich bei schlechtem Design sowie beim Übertreiben (exzessives Vererben, zu sehr spezialisierte Subklassen) die Vorteile in Nachteile wandeln, die Software wird schlechter wartbar, Wiederverwendung wird erschwert/unmoeglich. Ausserdem kann sich objektorientiertes Progammieren nachteilig auf die Performance auswirken (z.B.: dynamic binding).
Wenn also Eure Programme momentan leicht wartbar sind, alles funktioniert, performant ist und im Prinzip daher kein Bedarf besteht, dann wuerde ich von einer Umstellung absehen. Zumindest was die bestehenden Programme anbelangt. Bei Neuentwicklung kann man sich grundsaetzlich ueberlegen, kuenftig objektorientiert zu programmieren um die Vorteile zu nutzen.
... just my 2 cents.
Gruss,
Steff
Hallo Steff.Steff hat geschrieben:Hi,
grundsaetzlich: 'Never touch a running system'. Warum umstellen, wenn alles soweit funktioniert?!
Die offensichtlichen Vorteile ...
... just my 2 cents.
Gruss,
Steff
Ich glaube das mit der Umstellung habe ich falsch beschrieben. Alte Programme werden so bleiben wie sie sind. Aber Neuentwicklungen könnten wir mit ABAP - Objects schreiben. Das wäre der Vorschlag vom Chef. Ich weis eben nur nicht, ob ich diesen Vorschlag nun gut finden soll oder nicht
Weil ich auch nicht weis, ob das für mich als Programmierer eine große Umstellung sein wird, oder ob die Unterschiede nicht allzu groß sind, und eine schnelle Umgewöhnung auf die objektorientierte Programmierung möglich ist?Aber danke für die Antwort!
mfg Andi
Hauptsoch: HAUPTSOCH!
Hallo an dieser Stelle.
Grundlegend ist der Vergleich ABAP <-> ABAP Objects wie der Vergleich prozedurale Sprache <-> objektorientierte Sprache. Wer das objektorientierte beherrschen will, sollte erstmal die Niederungen der prozeduralen Programmierung kennen
Die Sprachelemente sind immerhin dieselben, aber in AO kommen noch weitere Konstrukte hinzu, die unter dem Ziel Release erstmal auf ihre Funktionsfähigkeit getestet werden sollten. Die Beispielprogramme der Workbench sollten hier Aufschluss geben.
Ein Buch zum Thema findet sich mit 'ABAP Best Practices' beim Galileo Verlag.
mfg M.L.
Grundlegend ist der Vergleich ABAP <-> ABAP Objects wie der Vergleich prozedurale Sprache <-> objektorientierte Sprache. Wer das objektorientierte beherrschen will, sollte erstmal die Niederungen der prozeduralen Programmierung kennen
Die Sprachelemente sind immerhin dieselben, aber in AO kommen noch weitere Konstrukte hinzu, die unter dem Ziel Release erstmal auf ihre Funktionsfähigkeit getestet werden sollten. Die Beispielprogramme der Workbench sollten hier Aufschluss geben.Ein Buch zum Thema findet sich mit 'ABAP Best Practices' beim Galileo Verlag.
mfg M.L.
Hallo Andi,
es gibt Entwicklungsanforderungen (z.B. einfache Auswertungen), bei denen macht es nur selten Sinn, OO zu benutzen, während bei kompexen Anwednungen es durchaus vorteilhaft ist.
Ich sehe das zur Zeit an einer Anwendung, die Materialstammdaten (mit Langtexten und kundeneigenen Daten) verwaltet. Dort habe ich das Material in eine (lokale) Klasse verbannt und daher ist mein Coding der Anwendung an sich recht gut überschaubar. Manipulationen an den Materialdaten laufen immer über Methoden, so dass die Anwendung keine Kenntnis der Daten und ihrer Strukturen hat, soweit dies nicht für sie relevant ist.
Bei der aktuellen Ergänzung konnte ich auf bestehende Methoden zurückgreifen und habe somit recht wenig Neues ergänzen müssen...
Was die Umgewöhung angeht, hängt es sehr von Dir persönlich ab, wie gut Du mit OO klarkommst. Für mich war es eher ein Finden der Präferenz als ein Umlernen, da ich wohl schon immer OO-lastig gedacht habe (viel kapseln, wiederverwenden).
Wenn Du viel mit globalen Daten arbeitest und Form-Routinen selten Parameter verwenden, wird es schwerer, als wenn Du ohnehin oft Funktionen und Form-Routinen verwendet hast, die ihre Daten möglichst nur Schnittstelle bekamen.
Betrachte ein Objekt mal als Funktionsgruppe, deren globalen Daten Du über die Funktionen (=> Methoden) ändern kannst. Beim Objekt kannst Du zusätzlich noch auf diese globalen Daten von aussen zugreifen, wenn Diese als PUBLIC definiert sind.
es gibt Entwicklungsanforderungen (z.B. einfache Auswertungen), bei denen macht es nur selten Sinn, OO zu benutzen, während bei kompexen Anwednungen es durchaus vorteilhaft ist.
Ich sehe das zur Zeit an einer Anwendung, die Materialstammdaten (mit Langtexten und kundeneigenen Daten) verwaltet. Dort habe ich das Material in eine (lokale) Klasse verbannt und daher ist mein Coding der Anwendung an sich recht gut überschaubar. Manipulationen an den Materialdaten laufen immer über Methoden, so dass die Anwendung keine Kenntnis der Daten und ihrer Strukturen hat, soweit dies nicht für sie relevant ist.
Bei der aktuellen Ergänzung konnte ich auf bestehende Methoden zurückgreifen und habe somit recht wenig Neues ergänzen müssen...
Was die Umgewöhung angeht, hängt es sehr von Dir persönlich ab, wie gut Du mit OO klarkommst. Für mich war es eher ein Finden der Präferenz als ein Umlernen, da ich wohl schon immer OO-lastig gedacht habe (viel kapseln, wiederverwenden).
Wenn Du viel mit globalen Daten arbeitest und Form-Routinen selten Parameter verwenden, wird es schwerer, als wenn Du ohnehin oft Funktionen und Form-Routinen verwendet hast, die ihre Daten möglichst nur Schnittstelle bekamen.
Betrachte ein Objekt mal als Funktionsgruppe, deren globalen Daten Du über die Funktionen (=> Methoden) ändern kannst. Beim Objekt kannst Du zusätzlich noch auf diese globalen Daten von aussen zugreifen, wenn Diese als PUBLIC definiert sind.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Hi Andy,
ich denke, man sollte sich langsam in die Materie einarbeiten. Es wird sowieso zunächst immer ein Mischcode bleiben, so wie es bei vielen SAP-Programmen auch ist.
Aber manche Dinge sind extrem elegant und da sollte man ansetzen. Ich denke da gerade an einfache Auswertungen. Einmal ein Musterprogramm mit Container und Events erstellen. Man braucht nur eine interne Tabelle, man kann mehrere Controls auf einem Dynpro erstellen und alles ist äußerst elegant. Ich möchte das nicht mehr missen, denn ein Programm für eine Auswertung ist wesentlich schneller erstellt und sieht für den User toll aus und es sind alle Funktionen wie Export, Druck, Sort...usw. in der Buttonleiste vorhanden.
Das oben genannte Buch ist in meinen Augen eines der besten. Erstell mal so eine Auswertung und spiel dann ein bißchen herum. Erst ein einfaches Ding mit einem Custom-Control und dann erstell mal ein Programm mit drei Controls. Spätestens dann wirst Du erkennen, wie elegant es mit OO möglich ist.
Sieh' Dir das SAP-Handbuch 'ALV Grid Control' an uind die SAP-Musterprogramme BCALV*. Und hol Dir aus dem Internet 'An Easy Reference for ALV Grid Control' von Serda Simsekler.
Okay, ALV ist nur ein Bereich, aber für mich der wichtigste und der, mit dem man anfangen kann. Und sollte.
Viel Spass!
Grayhound
ich denke, man sollte sich langsam in die Materie einarbeiten. Es wird sowieso zunächst immer ein Mischcode bleiben, so wie es bei vielen SAP-Programmen auch ist.
Aber manche Dinge sind extrem elegant und da sollte man ansetzen. Ich denke da gerade an einfache Auswertungen. Einmal ein Musterprogramm mit Container und Events erstellen. Man braucht nur eine interne Tabelle, man kann mehrere Controls auf einem Dynpro erstellen und alles ist äußerst elegant. Ich möchte das nicht mehr missen, denn ein Programm für eine Auswertung ist wesentlich schneller erstellt und sieht für den User toll aus und es sind alle Funktionen wie Export, Druck, Sort...usw. in der Buttonleiste vorhanden.
Das oben genannte Buch ist in meinen Augen eines der besten. Erstell mal so eine Auswertung und spiel dann ein bißchen herum. Erst ein einfaches Ding mit einem Custom-Control und dann erstell mal ein Programm mit drei Controls. Spätestens dann wirst Du erkennen, wie elegant es mit OO möglich ist.
Sieh' Dir das SAP-Handbuch 'ALV Grid Control' an uind die SAP-Musterprogramme BCALV*. Und hol Dir aus dem Internet 'An Easy Reference for ALV Grid Control' von Serda Simsekler.
Okay, ALV ist nur ein Bereich, aber für mich der wichtigste und der, mit dem man anfangen kann. Und sollte.
Viel Spass!
Grayhound
Hallo,
bei mir kommt das je nach Projekt immer öfter.
Ich hatte mal ein paar Tabellen als variablen Baum darzustellen.
OK, das ging noch herkömmlich mit Performs, Makros etc.
Dann sollte was aus den Tabellen als Liste dargestellt werden, und siehe da, das Coding wäre ähnlich gewesen, war aber so nicht recylebar.
Dann habe ich das ganze Tabellenpaket durch eine Klasse behandeln lassen.
Die Klasse liest schon beim Erzeugen des Objektes den "Schmonzes" ein und bereitet all das vor, was man später sowieso braucht (Feldkataloge etc.)
Im Haupt- oder Anzeigeprogramm rufe ich die Methode auf (Prepare_ALV) und dann rödelt das Ding, und gibt alles das zurück was ich für die ALV-Ausgabe brauche. Das zeige ich dann ALV-OO-mäßig an.
Danach kam die Anforderung, einen Extrakt aus dieser ALV-Tabelle irgendwohin zu exportieren.
Zuerst wollte ich wieder im Anzeigeprogramm über die Daten rödeln ... Aber halt, da war doch die Klasse und das Objekt. Da habe ich dann eine neue Methode an meine Klasse gefügt (Export_Data). Die kriegt den Handle vom Grid und dann kann sie selber rausfinden, welche Zeilen Spalten, Filter oder sonstwas gesetzt sind. (Alles andere kennt sie ja schon!)
Jetzt werde ich vielleicht (Running-System) auch die ursprüngliche Baumtransaktion in die Klasse "migrieren".
Das schöne an den Klassen ist, man kann sie unabhängig testen, ohne daß das logisch vorhergende oder nachfolgende (Anzeige-)Programm schon fertig sein muß.
Gruß
babap
bei mir kommt das je nach Projekt immer öfter.
Ich hatte mal ein paar Tabellen als variablen Baum darzustellen.
OK, das ging noch herkömmlich mit Performs, Makros etc.
Dann sollte was aus den Tabellen als Liste dargestellt werden, und siehe da, das Coding wäre ähnlich gewesen, war aber so nicht recylebar.
Dann habe ich das ganze Tabellenpaket durch eine Klasse behandeln lassen.
Die Klasse liest schon beim Erzeugen des Objektes den "Schmonzes" ein und bereitet all das vor, was man später sowieso braucht (Feldkataloge etc.)
Im Haupt- oder Anzeigeprogramm rufe ich die Methode auf (Prepare_ALV) und dann rödelt das Ding, und gibt alles das zurück was ich für die ALV-Ausgabe brauche. Das zeige ich dann ALV-OO-mäßig an.
Danach kam die Anforderung, einen Extrakt aus dieser ALV-Tabelle irgendwohin zu exportieren.
Zuerst wollte ich wieder im Anzeigeprogramm über die Daten rödeln ... Aber halt, da war doch die Klasse und das Objekt. Da habe ich dann eine neue Methode an meine Klasse gefügt (Export_Data). Die kriegt den Handle vom Grid und dann kann sie selber rausfinden, welche Zeilen Spalten, Filter oder sonstwas gesetzt sind. (Alles andere kennt sie ja schon!)
Jetzt werde ich vielleicht (Running-System) auch die ursprüngliche Baumtransaktion in die Klasse "migrieren".
Das schöne an den Klassen ist, man kann sie unabhängig testen, ohne daß das logisch vorhergende oder nachfolgende (Anzeige-)Programm schon fertig sein muß.
Gruß
babap
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
3827
Views
Views
3
Antw.
Antw.
5771
Views
Views
6
Antw.
Antw.
4428
Views
Views
0
Antw.
Antw.
2120
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1150
vor 2 Tagen von DeathAndPain 4 / 1150
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1150
vor 2 Tagen von DeathAndPain 4 / 1150