• Überblick bewahren
    • Technik beherrschen
    • Werte schaffen

Point of Views

SAP HANA

Die meisten Datenbanksysteme basieren immer noch auf schon lange etablierten Konzepten, der Spielraum für Performance-Verbesserungen ist eher gering geworden. Hier kommen In-Memory Databases ins Spiel

Read more ...

SAP AIF

Das SAP AIF schließt die Lücke der verstreuten Interface-Technologien und bietet ein einheitliches Framework ...

Read more ...

SAP OOP

Seit Mitte der 1980er Jahre wurde das Konzept der objektorientierten Programmierung (kurz: OOP) zunehmend populär ...

Read more ...

 

Einleitung

Seit Mitte der 1980er Jahre wurde das Konzept der objektorientierten Programmierung (kurz: OOP) zunehmend populär. Viele der heute in der Anwendungsentwicklung gebräuchlichen Programmiersprachen erhielten mit der Zeit objektorientierte Erweiterungen, andere – hier sei vor allem JAVA erwähnt – wurden von Grund auf objektorientiert konzipiert. ABAP wird seit 10-15 Jahren Stück für Stück um objektorientiert Konzepte erweitert.

Gerade im SAP-Umfeld konnte sich OOP bisher allerdings nicht umfassend durchsetzen. In den Programmierrichtlinien so mancher Unternehmen wird die Verwendung von ABAP Objects weiterhin strikt untersagt.

Die zumeist gewachsene IT-Struktur von großen und mittelständischen Unternehmen mit zum Teil seit Jahren etablierten und stetig erweiterten Programmen macht den Umstieg auf ABAP Objects schwierig.

Noch dazu befindet sich SAP selbst in einem Prozess der Umstellung auf OOP. Teile des SAP-eigenen Quellcodes werden Stück für Stück angepasst und mit OOP kompatibel gemacht. Viele neue Elemente der SAP-Landschaft setzen zu einem gewissen Teil OOP voraus.

Die meisten der mit SAP realisierten Lösungen in Unternehmen bilden jedoch kritische Geschäftsprozesse ab. Eine jeweilige Umstellung auf die neusten SAP-Releases ist somit bei einem funktionierenden System nicht immer sinnvoll, bedeutet in jedem Fall aber einen finanziellen und zeitlichen Aufwand. Somit kann nicht in jedem Unternehmen der volle Leistungsumfang von ABAP Objects genutzt werden.

Vor- und Nachteile

Häufig wird die Ablehnung von ABAP Objects damit begründet, dass ein Mehraufwand entstehe, der keine Vorteile biete oder sogar zu instabilem Code führe. Die OOP-Befürworter argumentieren vor allem mit einer besseren Datenkapselung, hoher Wiederverwendbarkeit und besser strukturiertem und damit besser wart- und erweiterbarem Code.

JAVA als rein OOP-basierte Programmiersprache wäre heute sicher nicht eine der bedeutendsten Anwendungssprachen, würde OOP rein konzeptionell zu instabilem Code führen. Die Stabilität von Code ist auch bei ABAP keine Frage des Programmierkonzepts. Stabiler Code entsteht durch gute Planung und saubere Programmierung.

Ein Mehraufwand durch ABAP Objects ist dagegen nicht von der Hand zu weisen. Ob durch die Nutzung in jedem Fall deutlich mehr Code entsteht ist fraglich. Allerdings entsteht ein Mehraufwand in der Planung und zum Teil in der Schulung der beteiligten Programmierer bezüglich OOP.

Dieser Mehraufwand kann allerdings durch die bessere Wart- und Erweiterbarkeit von ABAP Objects wieder wettgemacht werden. Zwar ist hier das wichtigste Kriterium in jedem Fall eine gute Dokumentation des Codes, jedoch bietet OOP mit seiner Orientierung an realen oder logischen Objekten gerade OOP-erfahrenen Programmierern die Möglichkeit, sich schneller in fremden Code einzuarbeiten. Zumindest dann, wenn die Konzepte und Möglichkeiten von OOP entsprechend professionell umgesetzt wurden.

Zu den modernen Konzepten in der Anwendungsprogrammierung zählt die logische Unterteilung eines Programms in Schichten. Ein einfaches 3-Schicht-Modell gliedert den Code beispielsweise in eine Persistenz-Schicht (Datenbank-Kommunikation), eine Präsentations-Schicht (User-Kommunikation) und eine Anwendungs-Schicht (Logik und Bindeglied zwischen Datenbank und User). Mithilfe der OOP ist eine natürlichere und saubere Umsetzung eines solchen Schichtmodells möglich. Bei einem Datenbank-Wechsel muss dann beispielsweise nur die Persistenz-Schicht ausgetauscht oder angepasst werden, der Rest des Programms kann unverändert weiter verwendet werden. Möchte man ein Programm auf verschiedenen Geräten verfügbar machen (SAP Gui, Browser, Mobil, etc.), so reicht es, einfach verschiedene Präsentations-Schichten zu erstellen, die anderen beiden Schichten sind davon nicht betroffen.

Ein weiteres Konzept ist die testgesteuerte Programmierung. Anhand von vorgegebenen Testfällen kann ein Programm im Laufe seiner Entwicklung jederzeit auf seine korrekte Funktionalität überprüft werden. ABAP Objects bietet hierfür Testklassen an, die einzeln oder gebündelt ausgeführt schnell etwaige Probleme im Entwicklungsprozesses aufzeigen können.

Unübersichtlich wird die Nutzung von ABAP Objects vor allem an den Stellen, wo durch gewachsene Strukturen die Nutzung von prozeduralen Konzepten nicht umgangen werden kann. So kann zwar ein großer Teil der DynPro-Programmierung in Klassen ausgegliedert werden, es bleibt jedoch prozeduraler Code vorhanden. Durch das OOP-basierte SAP Control Frameworkist hier eine zunehmende Vermischung beider Programmier-Konzepte zwar kaum zu verhindern, bedeutet jedoch einen Mehraufwand bei der ‚Vermittlung‘ zwischen den jeweiligen Code-Teilen.

Eine Umwandlung eines bestehenden prozeduralen Programms in ABAP Objects ist ebenfalls nicht ohne erheblichen Aufwand möglich. Von Fall zu Fall müsste die komplette Planung wiederholt werden, hier wäre ein sehr genauer Blick auf die zu erwartenden Vorteile durch die Umstellung nötig.

Schlussendlich ist noch die Frage nach der Performance zu bewerten. Ein Konzept wie OOP, das eine stärkere Orientierung an der menschlichen Denk- und Sprachlogik weg von reiner Maschinenlogik beinhaltet, führt immer zu einem gewissen Overhead. Dazu kommt, dass ABAP als Programmiersprache auf seine mächtigen Befehle hin optimiert ist. Methodenaufrufe sind in ABAP verhältnismäßig ‚teuer‘. Gerade OOP bedingt aber eine starke Kapselung und damit eine hohe Anzahl an Methodenaufrufen.

Betrachtet man allerdings die heutige IT- und Anwendungslandschaft, so kann man sagen:

Wirklich zeitintensive Prozesse sind die Datenbeschaffung und vor allem die Datenanalyse. Die Wahl des Programmierkonzepts und die dadurch vorgegebene Ablauflogik beeinflusst die Ausführungszeit eines Programmes somit relativ wenig. Dies gilt natürlich insbesondere bei einer sauberen und strukturierten Programmierung.

Fazit

OOP ist der prozeduralen Programmierung nicht grundsätzlich überlegen. Es besteht in vielen Fällen keine Veranlassung, bestehende Programme auf OOP umzustellen. Auch müssen neue Programme nicht grundsätzlich mit ABAP Objects realisiert werden. Allerdings erlangt ABAP Objects im SAP-Umfeld zunehmend an Bedeutung. SAP selbst verwendet für neue Features mehr und mehr OOP und passt ältere Komponenten entsprechend an. Viele allgemeine Trends in der Programmierung werden auf Basis von OOP erdacht und entwickelt.

Die Mitarbeiter der BoRemi GmbH kennen die Vorzüge der objektorientierten Programmierung, wissen aber auch um ihre Nachteile und Grenzen. Für uns steht nicht der programmatische Ansatz im Vordergrund, sondern das Ziel, stabile und performante Programme zu entwickeln. Sofern der Kunde keinen Ansatz vorgibt, wählen wir zwischen prozeduraler und objektorientierter Programmierung denjenigen Ansatz, der nach sorgfältiger Analyse den Anforderungen des Projekts besser entspricht.

Kontaktinformation


  Telefon: +49 (2330) 8 488 680
  Telefax: +49 (2330) 8 488 681
   eMail: c.bormann@boremi.de

 Anschrift


boremi GmbH
Zeppelinstr. 53a
58313 Herdecke
 
Copyright (c) boremi GmbH 2014. All rights reserved.
Designed by olwebdesign.com