Informationssysteme wurden früher vorwiegend über ihre Funktionalität definiert: Daten und Funktionen wurden getrennt voneinander gehalten und durch Input-Output-Beziehungen miteinander verknüpft.
Im Zentrum objektorientierten Denkens stehen dagegen Objekte, die abstrakte oder konkrete Dinge der realen Welt repräsentieren. Sie werden zunächst in ihrem Wesen und ihren Eigenschaften begriffen, die durch ihre innere Struktur und ihre Attribute (Daten) abgebildet werden. Das Verhalten der Objekte wird durch Methoden (Funktionalität) beschrieben.

Objekte bilden eine Kapsel, die Wesen und zugehöriges Verhalten verbindet. Objekte sollen es erlauben, die Modelle eines Problembereichs und eines zugehörigen Lösungsentwurfs möglichst eins zu eins widerzuspiegeln.
Typische Objekte in einer Business-Umgebung sind z.B. 'Kunde', 'Auftrag', 'Rechnung'. Beispiele für solche Objekte finden sich seit Release 3.1 im BOR (Business Object Repository) des SAP Web Application Servers ABAP. Das Objektmodell des BOR wird zum nächsten Release in ABAP Objects integriert indem die Objekttypen des BOR in die ABAP Klassenbibliothek migriert werden.
Eine vollständige Einführung in die Objektorientierung geht weit über diese Einführung in ABAP Objects hinaus. Im Folgenden werden daher nur einige Begriffe definiert, die in der Objektorientierung allgemeine Gültigkeit haben und dementsprechend auch in ABAP Objects Verwendung finden. In den weiteren Abschnitten wird näher auf die Verwendung dieser Begriffe in ABAP Objects eingegangen. Am Ende des Abschnitts finden Sie Literaturhinweise mit einer Auswahl von Büchern zur Objektorientierung.
Objekte sind Instanzen von Klassen und besitzen Daten namens Attribute besitzt und Dienste in Form von Methoden (auch Operationen oder Funktionen genannt) anbietet. Typischerweise operieren die Methoden auf privaten Daten (Attribute oder auch Objektzustand genannt), die nur für die Methoden des Objekts sichtbar sind. Die Attribute eines Objektes werden somit nicht vom Verwender direkt, sondern nur von den Methoden des Objektes verändert. Dies garantiert die innere Konsistenz des Objekts.
Klassen beschreiben Objekte. Technisch gesehen bilden Objekte Instanzen einer Klasse. Auf der Grundlage einer Klasse können theoretisch unbegrenzte Mengen gleichartiger Objekte erstellt werden. Jede Instanz einer Klasse (Objekt) besitzt eigene Werte für alle ihre Attribute und eine eindeutige Identität.
In Programmen werden Objekte über eindeutige Objektreferenzen adressiert und identifiziert. Objektreferenzen dienen dem Zugriff auf die Attribute und Methoden eines Objekts.
In der objektorientierten Programmierung bieten Objekte normalerweise die folgenden Eigenschaften:
Ein Objekt beschränkt die Sichtbarkeit seiner Ressourcen (Attribute und Methoden) für andere. Jedes Objekt hat eine Schnittstelle, die festlegt, wie andere Objekte oder Anwendungen mit ihm umgehen können. Die Implementierung des Objekts ist dagegen gekapselt, d.h. für die Außenwelt nicht sichtbar.
Eine Klasse kann aus einer anderen Klasse abgeleitet werden. Abgeleitete Klassen erben die Daten und Methoden der übergeordneten Klasse, können aber neue Methoden hinzufügen oder bestehende Methoden überschreiben.
Gleiche (gleichnamige) Methoden verhalten sich unterschiedlich in unterschiedlichen Klassen. In ABAP Objects wird Polymorphie durch die Redefinition von Methoden bei der Vererbung und durch Konstrukte namens Interface verwirklicht.
Der Nutzen der objektorientierten Programmierung liegt unter anderem in der Erreichung folgender Ziele:
· Komplexe Software-Systeme sollen leichter verständlich werden, da ein objektorientierter Aufbau eher die Realität abbildet als andere Programmiertechniken.
· Wenn Änderungen notwendig werden, sollten sie in objektorientierten Systemen lokal (auf Klassenebene) durchführbar sein, ohne Änderungen in anderen Teilen des Systems nach sich zu ziehen. Damit verringert sich der gesamte Änderungsaufwand.
· Die objektorientierte Programmierung unterstützt durch Polymorphismus und Vererbung die Wiederverwendbarkeit einzelner Komponenten.
· Bei objektorientierten Systemen wird weniger Überarbeitungs- und Wartungsaufwand erwartet, da viele Probleme schon beim Design erkannt und korrigiert werden.
Um diese Ziele zu erreichen, bedarf es:
· Objektorientierter Programmiersprachen.
Objektorientierte Programmiertechniken sind zwar nicht unbedingt von objektorientierten Programmiersprachen abhängig, ihre Effizienz hängt aber unmittelbar von der systemnahen Implementierung objektorientierter Sprachmittel ab.
· Objektorientierter Werkzeuge.
Objektorientierte Werkzeuge unterstützen die Erstellung objektorientierter Programme mit objektorientierten Programmiersprachen. Sie dienen der Ablage und Visualisierung der Entwicklungsobjekte und deren Beziehungen zueinander.
· Objektorientierter Modellierung.
Die objektorientierte Modellierung des Software-Systems ist die wichtigste und zugleich auch zeitaufwendigste und schwierigste Voraussetzung für das Erreichen obiger Ziele. Das objektorientierte Design umfaßt mehr als nur die objektorientierte Programmierung und bietet logische Vorteile, die von der eigentlichen Implementierung unabhängig sind.
Dieser Text gibt eine Übersicht über die objektorientierten Erweiterungen der Sprache ABAP. Die Benutzung dieser Sprachelemente wird an einfachen Beispielen dargestellt. Diese Beispiele erheben nicht den Anspruch, Vorbilder für objektorientiertes Design zu sein. Detaillierte Informationen zu den Sprachelementen von ABAP Objects finden Sie in der ABAP-Schlüsselwortdokumentation. Für eine ausführliche Einführung in die Thematik der objektorientierten Entwicklung sei an dieser Stelle auf die folgenden Literaturhinweise verwiesen.
Es gibt sehr viele Bücher zum Thema Objektorientierung (OO), also zu den verschiedenen objektorientierten Programmiersprachen, zu objektorientierter Analyse- und objektorientiertem Design zu Projektmanagement unter objektorientierten Aspekten, Pattern und Frameworks usw. Im folgenden finden Sie eine kleine Auswahl von guten Büchern zu den wichtigsten Themen:
· Scott Ambler, The Object Primer, SIGS Books & Multimedia (1996), ISBN: 1884842178
Ein sehr gutes Buch zur Einführung in Objektorientierung aus der Sicht eines Entwicklers / Programmierers. Es werden alle wesentlichen OO-Konzepte gut erklärt, und es wird ein Vorgehensmodell vorgestellt, um OO schnell und gründlich zu lernen. Das Buch ist leicht lesbar, angenehm praktisch und doch theoretisch fundiert.
· Grady Booch, Object Solutions: Managing the Object-Oriented Project, Addison-Wesley Pub Co (1995), ISBN: 0805305947
Ein gutes Buch über alle nicht-technischen Aspekte von OO, die aber für eine erfolgreiche Nutzung von OO genauso wesentlich sind. Leicht lesbar und voll von praktischen Tips.
· Martin Fowler, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley Pub Co (1997), ISBN: 0201325632
Ein ausgezeichnetes Buch zu UML (Unified Modelling Language, die neue einheitliche OO-Modellierungs-Sprache/Notation) und über die richtige Benutzung der UML Konzepte. OO-Kentnisse/Erfahrungen werden vorausgesetzt.
· Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides, Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley Pub Co (1998), ISBN: 0201634988
Pattern zeigen, wie immer wiederkehrende Design-Probleme mit Objekten gelöst werden können. Dies ist das erste große Pattern-Buch und eine Fundgrube für Beispiele von gutem OO-Design.
· James Rumbaugh, OMT Insights: Perspectives on Modeling from the Journal of Object-Oriented Programming, Prentice Hall (1996), ISBN: 0138469652
Eine Sammlung von Artikeln zu vielen Fragen und Problemen bei OO-Analyse und Design, und auch Implementierung, Management von Abhängigkeiten usw. Sehr empfehlenswert.
Wer zum ersten mal mit Objektorientierung arbeitet, sollte zu Beginn 'The Object Primer' von Scott Ambler lesen lesen und dann etwas praktische Erfahrung sammeln. Zur OO Analyse und Design sollte man unbedingt zuerst die CRC-Techniken anwenden, die gut bei Ambler und Fowler beschrieben sind. Danach sollte man sich mit UML beschäftigen, da dies die universale OO-Analyse- und Design-Notation ist. Schließlich sollte man auf jeden Fall ein Buch über Pattern lesen.
Wenn man ein größeres OO-Projekt beginnt, stellt sich sofort die Frage in welcher Reihenfolge was gemacht werden sollte, wann welche Phasen fertig sind, wie man die Entwicklungsarbeit partitioniert und organisiert, wie man Risiken minimiert, wie man ein gutes Team zusammenstellt, usw. Viele Fragen des guten Projektmanagement mußten für OO neu beantwortet werden, und die sich daraus ergebenden Möglichkeiten und Chancen sind durchaus bemerkenswert. Zum Thema, wie man OO beim Projektmangement nutzen kann, sind das Buch 'Object Solutions' von Grady Booch, und das Kapitel 'An outline development process' aus dem Buch von Martin Fowler lesenswert.
Es gibt natürlich viele andere gute Bücher zu den OO Themen. Die obige Liste erhebt keinen Anspruch auf Vollständigkeit oder darauf, wirklich die besten Bücher zu empfehlen.