Objektorientierte Programmierung

Grundidee und Definition

Objektorientierte Programmierung, kurz OOP, ist ein Programmierparadigma, das auf Objektorientierung beruht. Die Architektur einer Software soll sich an den Grundstrukturen des Wirklichkeitsbereichs orientieren, den die Anwendung beschreibt. In der Entwurfsphase entsteht dazu ein Modell mit Informationen über Objekte, ihre Abstraktionen und ihre Typen. Wichtige Konzepte für diese Denkweise sind Klassen, Vererbung, Polymorphie und spätes beziehungsweise dynamisches Binden.

Eine einheitliche Definition von OOP gibt es nicht. Alan Kay, der Erfinder von Smalltalk und des Begriffs „object oriented“, beschrieb OOP im Zusammenhang mit Smalltalk unter anderem so: Alles ist ein Objekt; Objekte kommunizieren durch Senden und Empfangen von Nachrichten; Objekte haben eigenen Speicher; jedes Objekt ist Instanz einer Klasse; die Klasse enthält gemeinsames Verhalten ihrer Instanzen; zur Ausführung einer Programmliste wird die Kontrolle dem ersten Objekt gegeben und der Rest als dessen Nachricht behandelt. Später betonte Kay, dass der Begriff „Objektorientierung“ aus seiner Sicht den Kernaspekt des Messaging zu wenig hervorhebe. 2003 formulierte er: OOP bedeute für ihn nur Messaging, lokales Beibehalten, Schützen und Verbergen des Prozesszustands sowie spätestmögliche Bindung aller Dinge.

Der ISO/IEC-2382-15-Standard von 1999 definiert „object-oriented“ einfacher als Technik oder Programmiersprache, die Objekte, Klassen und Vererbung unterstützt. Diese Definition gilt inzwischen als zu vereinfachend, weil es auch klassenlose objektorientierte Sprachen gibt und Vererbung weniger zentral bewertet wird als in den 1990er-Jahren.

Zentrale Konzepte

Die Bausteine eines objektorientierten Programms zur Laufzeit heißen Objekte. Ein Objekt kann als abstraktes Modell eines Akteurs verstanden werden: Es kann Aufträge erledigen, seinen Zustand berichten und ändern sowie mit anderen Objekten kommunizieren, ohne seine interne Implementierung offenzulegen. Solche Abstraktionen sind in klassenbasierter Objektorientierung Klassen, in prototypbasierter Programmierung Prototypen.

Eine Klasse legt die Datenstruktur eines Objekts durch Attribute fest und beschreibt sein Verhalten durch Methoden. Klassen können von anderen Klassen abgeleitet werden. Dabei erbt eine abgeleitete Klasse Attribute und Methoden einer Basisklasse. Ein Prototyp funktioniert anders: Neue Objekte entstehen durch Klonen vorhandener Objekte. Sie müssen nur die Unterschiede zum Prototyp definieren; Änderungen am Prototyp wirken dynamisch auch auf abgeleitete Objekte.

Datenkapselung bedeutet, Implementierungsdetails zu verbergen. Auf die interne Datenstruktur eines Objekts soll nicht direkt zugegriffen werden, sondern nur über definierte Schnittstellen. Dadurch können andere Objekte den internen Zustand nicht unerwartet lesen oder verändern, und Invarianten des Programms werden geschützt.

Feedback beschreibt die Kommunikation zwischen Objekten über Nachricht und Antwort. Diese Kommunikation kann Zustände verändern und neue Nachrichtenaufrufe auslösen; Kopplung dient dabei als Maß für den Grad des Feedbacks. Persistenz bedeutet, dass Objektvariablen bestehen bleiben, solange das Objekt existiert, und nicht nach dem Ablauf einer Methode verschwinden.

Polymorphie, also Mehrgestaltigkeit, ist die Fähigkeit eines Bezeichners, abhängig von seiner Verwendung unterschiedliche Datentypen anzunehmen. Verschiedene Objekte können auf dieselbe Nachricht unterschiedlich reagieren. Wird erst zur Laufzeit entschieden, welche Reaktion erfolgt, spricht man von später Bindung. Vererbung bedeutet vereinfacht, dass eine abgeleitete Klasse Methoden und Attribute der Basisklasse besitzt und darauf zugreifen kann. Neue Objektarten können so auf bestehenden Objektdefinitionen aufgebaut, erweitert oder überlagert werden.

Objekte, Klassen, Methoden und Attribute

Ein Objekt ist ein Element, das Funktionen, Methoden, Prozeduren, einen inneren Zustand oder mehrere dieser Dinge besitzt. Eine Entität ist ein Objekt mit eindeutiger Identität zur Speicherung von Daten. Das Beispiel im Artikel ist eine Person mit Adresse, Telefonnummer oder Name: Die Daten können sich ändern, ohne dass die Person ihre Identität verliert. Ein Wertobjekt wird dagegen über seinen Wert definiert. Eine geänderte Telefonnummer ist eine andere Telefonnummer; ebenso ist eine Adresse mit anderer Hausnummer eine andere Adresse.

Eine Eigenschaft ist ein Bestandteil des Zustands eines Objekts und kann eine Entität oder ein Wertobjekt sein. Ein Dienst ist ein Objekt, das Verhalten, zum Beispiel Geschäftslogik, in Form von Prozeduren, Funktionen oder Methoden implementiert und dabei Entitäten oder Wertobjekte verwendet. Eine Prozedur verändert den Zustand eines Objekts ohne Rückgabewert. Eine Funktion ordnet einer Eingabe einen Rückgabewert zu und verändert den Zustand eines Objekts nicht. Eine Methode verändert den Zustand eines Objekts und liefert zusätzlich einen Rückgabewert. Ein Modul ist eine zusammengefasste Gruppe von Objekten.

Die meisten Programmiersprachen nutzen Klassen, um gleichartige Objekte besser zu verwalten. Klassen sind Vorlagen, aus denen zur Laufzeit Instanzen, also Objekte, erzeugt werden. Wenn eine Sprache keine Klassen besitzt oder diese ausdrücklich unterdrückt werden, spricht man zur Unterscheidung oft von objektbasierter Programmierung. Eine Klasse ähnelt einem komplexen Datentyp aus der prozeduralen Programmierung, geht aber darüber hinaus: Sie legt nicht nur Daten fest, sondern auch die Algorithmen, die auf diesen Daten arbeiten.

Das Artikelbeispiel nutzt die Klasse „Auto“. Sie legt fest, dass ein Auto vier Reifen einer bestimmten Größe, fünf farbige Türen, einen Motor bestimmter Leistung und fünf Sitze mit wählbaren Bezügen hat. Die Objekte „Auto1“ und „Auto2“ besitzen jeweils vier Reifen mit 19 Zoll Durchmesser und 255 mm Breite, fünf rote Türen, einen Motor mit 150 kW und fünf Ledersitze. „Auto3“ besitzt vier Reifen mit 16 Zoll Durchmesser und 205 mm Breite, fünf blaue Türen, einen Motor mit 90 kW und fünf Sitze mit Textilbezug. Alle drei sind Instanzen der Klasse „Auto“, auch wenn zwei dieselben Attribute haben.

Algorithmen, die einer Klasse zugeordnet sind, heißen Methoden. Besondere Methoden zur Erzeugung und Zerstörung von Objekten heißen Konstruktoren und Destruktoren. Methoden können Parameter und Rückgabewerte haben; eine Methode „addiere“ könnte etwa Zahl 1 und Zahl 2 erhalten und deren Summe zurückgeben. Viele Sprachen unterscheiden Zugriffsebenen: public für alle Klassen, protected für Klassen im selben Paket und abgeleitete Klassen, Paket-Ebene für Klassen im selben Paket, und private nur für Methoden derselben Klasse. Attribute sind Eigenschaften eines Objekts, zum Beispiel Farbe, Größe oder Ausrichtung bei Fenstern, Schaltflächen, Laufleisten oder Menüs.

Polymorphie und Programmiersprachen

Polymorphie ermöglicht, dass Algorithmen, die auf Schnittstellen eines bestimmten Objekttyps arbeiten, unter bestimmten Voraussetzungen auch mit Objekten abgeleiteter Klassen zusammenarbeiten. Wenn eine durch Vererbung überschriebene Methode statt der Methode der Basisklasse ausgeführt wird, spricht man von Polymorphie. So kann eine Aktion einen gemeinsamen Namen haben, während jede Klasse sie passend zum jeweiligen Objekt implementiert. Diese Technik heißt Overriding. Der Artikel betont, dass Overriding keine universelle Polymorphie implementiert, sondern Ad-hoc-Polymorphie.

Objektorientierte Programmiersprachen unterstützen die Strukturierung mit dem speziellen Datentyp Objekt. Ein objektorientierter Programmierstil ist zwar in nahezu jeder Sprache möglich, aber objektorientierte Sprachen erleichtern ihn. Rein objektorientierte Sprachen wie Smalltalk folgen dem Prinzip „Alles ist ein Objekt“. Auch elementare Typen wie Ganzzahlen werden dort durch Objekte repräsentiert; selbst Klassen sind Objekte und Exemplare von Metaklassen. Verbreitete Sprachen wie C#, C++ und Java behandeln das Objektprinzip weniger streng: Elementare Datentypen sind dort keine vollwertigen Objekte, und Entwickler können selbst entscheiden, wie stark sie objektinterne Daten kapseln.

Die erste bekannte objektorientierte Programmiersprache war Simula-67. Smalltalk baute später die Prinzipien der Kapselung in einer Klassenhierarchie weiter aus. Mit ANSI/X3.226-1994 wurde Common Lisp/CLOS zur ersten standardisierten objektorientierten Programmiersprache; mit ISO 8652:1995 wurde Ada 95 als erste nach internationalem ISO-Standard normierte objektorientierte Programmiersprache festgelegt. Moderne Sprachen wie Python unterstützen sowohl OOP als auch prozedurale Programmierung, die in klassischen Sprachen der 1970er- und 1980er-Jahre wie Pascal, Fortran oder C vorherrschte.

Techniken und Entwurf

Nicht alle objektorientierten Sprachen arbeiten mit Klassen. In Sprachen wie Go, NewtonScript und Self wird auf Klassendeklarationen verzichtet. Neue Objekte werden dort von bestehenden Objekten, den Prototypen, abgeleitet. Attribute und Methoden des Prototyps gelten, wenn sie im abgeleiteten Objekt nicht ausdrücklich überschrieben werden. Das kann besonders für kleinere Programme einfacher und zeitsparender sein.

In manchen Sprachen, etwa Objective-C, gibt es zu jeder Klasse ein Klassenobjekt, das die Klasse zur Laufzeit repräsentiert. Dieses Klassenobjekt ist dann auch für die Erzeugung von Objekten der Klasse und für den Aufruf der richtigen Methode zuständig. Klassen werden häufig in thematisch organisierten Klassenbibliotheken zusammengefasst. Solche Bibliotheken können zum Beispiel den Zugriff auf Datenbanken ermöglichen.

Beim Entwurf objektorientierter Modelle kann die sprachliche Problembeschreibung helfen. Die sogenannte Verb-Substantiv-Methode nutzt Wortarten als Hinweise: Substantive deuten oft auf Objekte und Klassen hin, Eigennamen eher auf konkrete Objekte, allgemeine Hauptwörter wie Haus oder Tier eher auf Klassen. Verben stehen meist für Methoden. Adverbien und Substantive können Methoden genauer beschreiben. Werte von Objektattributen entsprechen häufig Numeralien oder Adjektiven.

Weitere Verfeinerungen der OOP sind Entwurfsmuster, Design by contract und grafische Modellierungssprachen wie die Unified Modeling Language, kurz UML. Außerdem gewinnt aspektorientierte Programmierung an Bedeutung. Dabei werden Aspekte von Eigenschaften und Abhängigkeiten beschrieben. Erste Ansätze sieht der Artikel beispielsweise in Java mit Jakarta EE oder in abstrakter Datenhaltung über Persistenzschichten.

Grenzen und Kritik

OOP hat je nach Anwendungsfeld und Problemstellung Vor- und Nachteile. Wie andere Programmierparadigmen kann sie reale Probleme abbilden, aber manche Probleme lassen sich nur schwer geschickt mit OOP-Techniken modellieren. Als typisches Beispiel nennt der Artikel das Kreis-Ellipse-Problem.

Objektorientierte Programmiersprachen können mit natürlichen Sprachen verglichen werden. In OO-Sprachen stehen die Objekte im Mittelpunkt, sprachlich also Substantive. Aktionen, also Verben, sind sekundär, fest an Objekte gebunden und im Allgemeinen nicht eigenständig. In natürlichen Sprachen und in prozeduralen Sprachen können Verben unabhängig von Substantiven beziehungsweise Daten vorkommen. Daraus kann folgen, dass manche Probleme in objektorientierten Sprachen unnötig kompliziert beschrieben werden.

Ein häufig genannter Vorteil von OOP ist bessere Wartbarkeit und Wiederverwendbarkeit des statischen Quellcodes. Gleichzeitig werden Kontrollflüsse und dynamisches Laufzeitverhalten meist den Daten und Objekten untergeordnet, abstrahiert und gekapselt. Dadurch sind Kontrollflüsse für Entwickler weniger direkt in den Codestrukturen sichtbar als etwa in prozeduralen Sprachen. Hardware-nahe Sprachen wie C oder Assembler bilden echten Kontrollfluss und Laufzeitverhalten transparenter ab. Bei paralleler Hardware und nebenläufigem Code wird Kontrolle über komplexe Kontrollflüsse wichtiger, was mit OOP schwierig sein kann.

Ein weiterer kritischer Bereich ist die Verbindung mit relationalen Datenbanken. OOP-Objekte lassen sich nicht vollständig direkt auf relationale Datenbanken abbilden, und umgekehrt können relationale Datenbanken über OOP nicht in allen Stärken genutzt werden. Diese Lücke heißt object-relational impedance mismatch. Es gibt viele Ansätze, etwa objektrelationale Abbildung, aber keine allgemeingültige Lösung ohne Nachteile.

Auch Laufzeitverhalten und Energieeffizienz werden kontrovers diskutiert. Alexander Chatzigeorgiou verglich an der Universität Makedonien prozedurale C-Varianten und OOP-nahe C++-Varianten typischer Algorithmen: Gauß-Jordan-Algorithmus, Trapez-Integration und QuickSort. Auf dem verwendeten ARM-Prozessor waren die prozeduralen C-Algorithmusvarianten im Mittel um 48,41 % laufzeiteffektiver. Die C++-Varianten hatten im Mittel eine um 95,34 % höhere Leistungsaufnahme als die C-Varianten. Der Artikel nennt als Gründe allgemeine Abstraktions-Leistungseinbußen und deutlich mehr Arbeitsspeicherzugriffe durch OOP-Techniken, weist aber auch darauf hin, dass solche Algorithmen meist nur einen Teil von Anwendungen ausmachen.

In der Kritik untersuchte Luca Cardelli 1996 OOP-Ansätze anhand von Programmablaufgeschwindigkeit, Kompilationsgeschwindigkeit, Entwicklungseffizienz für große und kleine Teams sowie Eleganz des Sprachumfangs. Er kam zu dem Schluss, dass objektorientiertes Sprachdesign noch viel vom prozeduralen Sprachdesign lernen müsse, besonders bei Modularisierung, Datenabstraktion und Polymorphismus. Eine Studie von Potok et al. aus dem Jahr 1999 fand keine signifikanten Produktivitätsunterschiede zwischen OOP und prozeduralen Ansätzen, wobei Produktivität als entwickelte oder geänderte Programmzeilen pro Zeiteinheit gemessen wurde. Die Autoren nannten mögliche Verzerrungen, etwa scheinbar objektorientäre, aber tatsächlich prozedurale Software, zu wenige untersuchte Generationen objektorientierter Software und unterschiedlich qualifizierte Teams, hielten diese Punkte jedoch nicht für zutreffend.