Die Idee des objektorientierten Programmierens

Eigentlich ist die Bezeichnung "objektorientiertes Programmieren" unpassend, denn diese Technik müßte viel eher "typorientiertes Programmieren" oder noch besser "typbildendes Programmieren" genannt werden. Der Gedanke, der dahinter steckt, soll den Wunsch nach der Wiederverwendbarkeit von Programmteilen erfüllen. Dieser Wunsch entsteht durch den Umstand, daß viele Dinge immer wieder neu programmiert werden (müssen), obwohl es längst Lösungen dazu gibt.

Die Lösung ist recht einfach, und fast jeder Programmierer versucht nach diesem Prinzip zu arbeiten, ohne sich unbedingt bewußt zu sein, objektorientiert zu programmieren.

Man beschreibt dabei niemals sofort eine konkrete Systemkomponente. Das bedeutet, daß man niemals sofort ein konkretes Menü, ein konkretes Textfenster oder eine konkrete Datenbank programmiert. Stattdessen beschreibt man nur allgemeine (abstrakte) Objekte. Man programmiert also zunächst ein allgemeines Menü, ein allgemeines Textfenster oder eine allgemeine Datenbank.

Erst danach und an der Stelle, wo die Objekte zum Einsatz kommen, konkretisiert man sie. Dort gibt man dann nämlich an, man möchte ein Menü mit folgenden konkreten Einträgen, ein Textfenster mit folgendem konkreten Text als Inhalt oder eine Datenbank zur Speicherung von Daten der folgenden konkreten Datentypen.

Typenbildung

Sie sehen, daß man zunächst also nur Typen bildet: Menü, Textfenster und Datenbank. Dann "programmiert" (beschreibt) man ein allgemeines Objekt eines jeden dieser Typen. Erst später am Einsatzort legt man dann fest, daß man ein konkretes Objekt diesen Typs mit bestimmten konkreten Eigenschaften einsetzen möchte.

Die Forderung, die sich an die Implementation eines abstrakten Objektes stellt, ist die, daß beliebig viele konkrete Objekte dieses Typs nebeneinander existieren können, ohne sich in die Quere zu kommen. Wer ein allgemeines Menü oder Textfenster programmiert, muß darauf achten, daß später beliebig viele Menüs oder Textfenster anlegt werden können, und daß sich dann alle diese Menüs und Textfenster nicht gegenseitig beeinflussen. Daher dürfen in solchen Objekten keine globalen Variablen verwendet werden. Sie sind in gewissem Maße von der Außenwelt isoliert.

Bei der objektorientierten Programmierung geht man diesen Weg im Allgemeinen sehr radikal. Das heißt, daß man nur allgemeine Objekte beschreibt und im Prinzip niemals wirklich konkret wird. Selbst eine komplette Textverarbeitung sieht man dann als allgemeines Objekt an, und der Benutzer kann so viele dieser Textverarbeitungen starten (und damit konkretisieren), wie er möchte.

Strukturiertes Programmieren

Sie kennen den Begriff des "strukturierten Programmierens". Dabei meidet man GOTO-Befehle und benutzt stattdessen besondere Strukturen für Schleifen, Fallunterscheidungen und Unterprogramme (mit lokalen Variablen). Objektorientierung ist ebenfalls nur eine weitere Strukturierung. Dabei meidet man globale Speicher und benutzt besondere Strukturen zur Typbildung.

Der Klassenbegriff

Der Vollständigkeit sei noch erwähnt, daß alle Objekte gleichen Typs gemeinsam eine Klasse bilden. Diese Objekte sind also Mitglieder ihrer Klasse oder - andersrum - Exemplare ihres Typs. Auch hier noch ein Beispiel: Jeder konkrete Baum ist ein Exemplar des Typs Baum und Mitglied der Klasse aller Bäume.

Viele verstehen unter der objektorientierten Programmierung die Wahl eines bestimmten Ansatzes beim Entwurf eines Programms. Bei diesem Ansatz ermittelt man zunächst die Struktur der Daten, die mit Hilfe des Programms später verwaltet werden sollen. Eine Textverarbeitung muß beispielsweise auf den Daten, die ein Textdokument beschreiben, darin einbegriffen vielleicht Daten von Bildern, Tabellen usw., operieren. Eine Flugzeugsimulation muß mit Daten über das Flugzeug, die Umgebung, das Wetter usw. umgehen. Erst danach werden die Operationen auf diesen Daten beschrieben (z.B. "Bild in das Textdokument einfügen" oder "Schub des Flugzeuges erhöhen").

In der Tat ist dieser Ansatz in aller Regel sehr sinnvoll, denn spätere Änderungen am Programm sind oft Änderungen an der Funktionalität, nicht aber an den zugrundeliegenden Daten. Wenn der Flugzeugsimulator beispielsweise nachträglich um die Funktion eines Autopiloten ergänzt wird, so benötigt der Autopilot kaum neuen Daten. Wenn eine klare Struktur aller im System auftauchenden Daten vorliegt, kann darauf basierend der Autopilot also sehr leicht eingebaut werden. Schwer hat man es hingegen, wenn sich die dem System auferlegte Struktur hauptsächlich an den ursprünglichen Funktionen, nämlich die Bedienung des Flugzeuges per Joystick, orientiert.

Dieser Ansatz ist in aller Regel also von großem Vorteil, hat aber mit dem hier vermittelten Begriff der Objektorientierung nichts zu tun. Man müßte das Vorgehen vielleicht als "operandenorientiert" bezeichnen.

Beide Orientierungen lassen sich aber sehr schön verknüpfen, wenn man sich nämlich zuerst Gedanken über die zu verwaltenden Datentypen macht. Der Erfolg wäre der, daß die Textverarbeitung dann mit beliebig vielen Dokumenten und die Flugzeugsimulation mit beliebig vielen Flugzeugen und Umgebungen gleichzeitig umgehen könnte.

Ein erstes Beispiel zur Objektorientierung