Übersicht:
Objekte stehen im Zentrum objektorientierter Sprachen, daher auch der Name ObjektOrientierte Programmierung (engl. object oriented programming) oder kurz OOP. Überlegen Sie sich mal welche Objekte Sie im Alltagsleben antreffen: Ihren Hund, Ihren Schreibtisch, Ihr Radio, Ihr Fahrrad usw. Diese Objekte besitzen zwei Merkmale: sie besitzen Zustände (engl. state) und ein Verhalten (engl. behaviour). Ihr Hund, zum Beispiel, besässe die Zustände Name, Haarfarbe, Grösse, Hunger und hätte je nach Zustand folgendes Verhalten: beissen, bellen, winseln, rennen. Fahrräder kennen die Zustände Anzahl Gänge, aktueller Gang, zwei Räder und das Verhalten bremsen, beschleunigen, Gang wechseln.
Wir beobachten nun einen Fahrradfahrer und versuchen daraus ein Fahrradmodell zu entwerfen. Wir messen die Geschwindigkeit (10 km/h), die Pedalenkadenz (90 Umdrehungen pro Minute) und erkennen, dass der 5. Gang eingelegt ist. Unsere Beobachtungen lassen zudem folgende Funktionen für die Änderung der gemessenen Zustände erkennen: Pedalenfrequenz erhöhen/erniedrigen, Gang wechseln und bremsen. Das so erhaltene Modell sieht grafisch dargestellt wie folgt aus.
Software Objekte werden nach der realen Welt modelliert. Sie haben Zustände und besitzen ein Verhalten. Die Zustände werden in Variablen gespeichert, das Verhalten wird mit Methoden implementiert.
In den obigen Bildern sind die Variablen des Objektes im Zentrum, umschlossen von den Methoden, gezeichnet. Dies deutet grafisch an, dass Variablen gegen Zugriffe von aussen geschützt sind, d.h. Programme können nicht direkt auf die Variablen des Objektes zugreifen, sondern müssen die entsprechenden Methoden aufrufen. Dieser Schutz wird in der OOP Welt Kapselung (engl. encapsulation) genannt. Mit Kapselung werden Implementationsdetails versteckt. Um den Gang des Fahrrades zu wechseln, müssen wir nicht den Gangmechanismus verstehen. Das Wissen über den Ganghebel reicht aus. Selbst wenn wir unsere 3 Gangschaltung gegen eine 30 Gangschaltung austauschen, wissen wir immer noch, wie ein anderer Gang eingelegt wird, sofern die Funktion des Ganghebels nicht geändert hat.
Vorteile der Kapselung:
Mit einem einzigen Objekt können wir noch nicht viel anfangen. Normalerweise wird ein Objekt als Komponente eines grösseren Programmes, welches mehrere dutzend Objekte enthält, eingesetzt. Erst durch das Zusammenspiel mehrerer Objekte können wir höhere Funktionalität und komplexeres Verhalten erhalten. Unser Fahrrad in der Garage ist nur ein Gerüst aus Metall und Gummi, unfähig von selbst eine Aktivität zu entwickeln. Das Fahrrad wird erst dann sinnvoll eingesetzt, wenn es von einem anderen Objekt (von Ihnen) aktiviert wird (Sie betätigen kräftig die Pedalen).
Softwareobjekte agieren und kommunizieren untereinander indem sie sich gegenseitig Meldungen (engl. messages) schicken.
Manchmal muss einer Meldung zusätzliche Informationen mitgeben werden, damit das Objekt etwas sinnvolles mit der Meldung machen kann. Es genügt zum Beispiel nicht, dass wir dem Fahrrad mitteilen den Gang zu wechseln. Wir müssen zusätzlich noch angeben welchen Gang wir wünschen. Diese Information wird, wie in den Programmiersprachen C und Pascal, als Parameter der Meldung übergeben.
Eine Meldung umfasst drei Komponenten:
Diese drei Komponenten genügen um einem Objekt eine Meldung zu schicken.
Vorteile der Meldungen:
In Java entspricht der Aufruf einer Methode dem Schicken einer Meldung. Deshalb sprechen wir von Methodenaufruf anstelle von Meldung verschicken.
Oft finden wir mehrere Fahrräder gleicher Art. Es gibt Moutainbikes, Citybikes, Rennräder, Tandems usw. All diese Fahrradtypen besitzen gemeinsame Zustandsmerkmale (aktueller Gang, Pedalenkadenz, zwei Räder) und gemeinsame Verhaltensmerkmale (Gang wechseln, bremsen). Fahrradhersteller nützen diesen Vorteil aus und stellen mehrere Fahrräder des gleichen Typs her. Es wäre höchst ineffizient für jedes individuelle Fahrrad einen neuen Typ zu erfinden.
Wie der Fahrradhersteller können auch wir Vorteile aus der Tatsache von gemeinsamen Merkmalen nutzen und mehrere Objekte desselben Typs erzeugen. In der objektorientierten Welt sprechen wir jedoch nicht von Arten, sondern von Klassen (engl. classes).
Unser rotes Fahrrad zu Hause (= Objekt) ist zum Beispiel ein Citybikes. Wiederum spricht die OOP Welt eine andere Sprache. Unser Fahrrad ist eine Instanz (engl. instance) der Klasse Citybike.
Der Ausdruck "Objekt"
Wie Sie vielleicht aus den Diagrammen über Klassen und Objekte bemerkt haben, sind diese einander sehr ähnlich. Tatsächlich ist der Unterschied zwischen Klassen und Objekten oft der Grund von Missverständnissen und Problemen. Im täglichen Leben ist es klar, dass Klassen selber nicht Objekte sind, welche sie beschreiben. Ein Blauplan eines Fahrrades ist nicht das Fahrrad. In Programmen ist es schwieriger zwischen Klassen und Objekten zu unterscheiden. Software Objekte sind sozusagen elektronische Modelle der realen Welt oder abstrakte Konzepte. Zusätzlich wird der Ausdruck "Objekt" meistens inkonsistent verwendet, und Klassen und Instanzen zusammen werden manchmal ebenfalls Objekte genannt. Umgangsprachlich können wir den Unterschied wie folgt festhalten: Die Klasse entspricht einem Bauplan; Objekte sind Produkte, welche aus unserem Bauplan hervorgehen. Bevor wir ein Haus bauen erstellen wir einen Bauplan. Mit Hilfe dieses Bauplans können wir nachher beliebig viele Häuser bauen. Im Softwaremodell ist der Hausbauplan unsere Klasse, die Häuser sind Instanzen davon.
Methoden und Variablen einer Klasse werden erst real, wenn eine Instanz der Klasse erzeugt wird. In den Diagrammen wird dies mit schattierten Flächen angedeutet.
Vorteil von Klassen
Als im letzten Jahrhundert das Fahrrad erfunden wurde, gab es nur einen Typ von Fahrrad. Erst später wurde das Urfahrrad weiterentwickelt und Damenfahrräder, Tandems und Rennräder hergestellt. Dabei nahmen die Ingenieure das bestehende Fahrrad, fügten neue Funktionalitäten wie eine Gangschaltung hinzu, verbesserten die Bremsen und den Sitz, und gaben dem Fahrrad ein neues, modernes Aussehen. Das Verhalten des Fahrrades änderte sich jedoch nicht. Wir müssen immer noch in die Pedalen treten um das Fahrrad zu bewegen, oder die Bremsen drücken, wenn wir langsamer fahren möchten.
Eine ähnliche Entwicklungsmöglichkeit bietet OOP an. Wir können neue Klassen mit Hilfe anderer Klassen programmieren. Unser Fahrradbeispiel können wir wie folgt modellieren: Die Klasse Fahrrad ist unser Urfahrrad mit Eigenschaften und Verhalten die allen Fahrrädern gemeinsam sind. Danach erweitern wir die Klasse, fügen neue Eigenschaften hinzu und ändern bestehende ab. Somit erhalten wir unsere Mountainbike-, Citybike-, Rennräder- und Tandemklasse. Diese Klassen werden in OOP Unterklasse (engl. subclasses) von der Klasse Fahrrad genannt. Die ursprüngliche Fahrradklasse wird Oberklasse (engl. superclass) der Moutainbikes, Citybikes, Rennräder und Tandems genannt.
Jede Unterklasse vererbt (engl. inherit) die Zustände in Form der Variablen von der Oberklasse. Moutainbikes, Citybikes, Rennräder und Tandems besitzen gemeinsame Zustandsmerkmale Kadenz, Geschwindigkeit usw., welche sie von der Oberklasse Fahrrad geerbt hat.
Unterklassen werden aber nicht durch die Zustände und das Verhalten der Oberklasse eingeschränkt. Unterklassen können Variablen und Methoden zu den geerbten Variablen und Methoden von der Oberklasse hinzufügen. Tandems, zum Beispiel, benötigen zwei Sitze und zwei Lenker.
Unterklassen können sogar geerbte Methoden überschreiben (engl. override) und spezialisierte Implementationen zur Verfügung stellen. Tandems sind oft mit Trommelbremsen ausgestattet. Die Oberklasse Fahrrad vererbt eine Bremse, die durch unsere verbesserte Trommelbremse ausgetauscht wird.
Klassen sind nicht auf eine Vererbungsebene beschränkt. Die Klassenhierarchie kann beliebig gross werden. Methoden und Variablen werden vererbt und weitervererbt. Je weiter unten in der Hierarchie eine Klasse definiert ist, um so spezialisierter ist ihr Verhalten.
Vorteile der Vererbung
OOP Begriffe - Mandelbrot- und Julia-Mengen - Tips und Hinweise - Lösungsmöglichkeit
OOP - Werkzeuge - Referenzen - Fäden - Synchronisation - Applets - Dokumentation
Werkstatt - Bibliographie