Ausgewählte Basiskonzepte der Objektorientierung sollen hier kurz umrissen werden. Sie müssen diesen Teil nicht unbedingt lesen, um das Tutorial nachzuvollziehen. Es lohnt jedoch in jedem Falle, sich intensiver mit dieser Problematik zu beschäftigen. Zum objektorientierten Paradigma zählen folgende Konzepte:

• Abstraktion
• Objekte mit Eigenschaften, Verhalten und Zuständen
• Klassen als abstrahierte Objekte
• Vererbung zum Abstrahieren von Klassen (Generalisierung, Spezialisierung)
• Kapselung und Nachrichten, um Merkmale zu schützen
• Assoziation, Aggregation und Komposition
• Polymorphie

lat. abstractus „abgezogen“, von abs-trahere „abziehen, entfernen, trennen“ Bedeutung: von der Gegenständlichkeit losgelöst

Nicht erschrecken. Die Herleitung des Begriffs ist wichtig. Verweilen Sie einen Moment bei dem Gedanken: „… von der Gegenständlichkeit losgelöst“. Das bedeutet nichts anderes, als dass wir in der Lage sind, mit etwas umzugehen, ohne dass es da sein muss. Frauen reden über Männer sogar am eifrigsten, wenn diese nicht anwesend sind! Und damit haben wir auch schon den Bogen zur Sprache geschlagen. Sprache ist Ausdruck der uns von Natur aus gegebenen Fähigkeit zu abstrahieren. Das Gegenständliche bilden wir in Begriffen ab. Und mehr soll an dieser Stelle dazu auch nicht gesagt werden.

Wir geben den Dingen Namen.

Womit wir beim nächsten Punkt sind. Dinge bezeichnet der Fachmann als Objekte und mal ehrlich, Dingorientierung klingt auch nicht wirklich sexy. Also dann doch lieber Objektorientierung. Objekte, das sind die Bausteine, aus denen die Systeme, welche wir programmieren wollen, bestehen. Für uns sind das zum Beispiel das Programm selbst, die Applikation, vielleicht eine bestimmte Schaltfläche, ein Button oder eine Liste usw.. Diese Objekte besitzen konkrete Eigenschaften und typisches Verhalten. Die Applikation hat eine bestimmte Hintergrundfarbe, die Schaltfläche kann gedrückt werden und die Liste hat einen dünnen Rahmen. Die Eigenschaften bilden wir in Programmen als Variablen (Attribute) und das Verhalten als Funktionen (auch Methoden bzw. Operationen genannt) ab. Programmieren wir objektorientiert, müssen wir dafür sorgen, dass auch das Programm aus genau diesen Objekten besteht und die Attribute und Operationen diesen Objekten zugeordnet sind.

Die Bausteine, aus denen das System besteht, sind der Ausgangspunkt der Softwareentwicklung. Diese Bausteine bezeichnen wir als Objekte.

Der Name, welchen wir für ein Ding benutzen, bezeichnet meist nicht nur das einzelne Ding, sondern eine Menge (Gruppe) gleichartiger Dinge. Nehmen wir zum Beispiel den Button. Davon haben wir in unserer Anwendung schon mal zwei Stück. Um diese zu unterscheiden, geben wir jedem noch einen individuellen Namen, zum Beispiel Ende und Hilfe. Button steht also als Begriff für alle Schaltflächen mit den entsprechenden gleichen Eigenschaften. Der Fachmann bezeichnet so etwas als Kategorie oder auch als Klasse. Die beiden Objekte Button Ende und Button Hilfe sind Bausteine unseres Systems und gehören zur Klasse (Gruppe) der Schaltflächen (Button). Unser oberschlauer Fachmann bezeichnet diese beiden konkreten Objekte auch gern als Instanzen der Klasse Button. Übrigens kennen wir diese Problematik schon aus der klassischen Programmierung in Form von Typen und Variablen. Klassen sind die Typen und die Objekte so etwas wie die Variablen.

Wir geben einer Menge gleichartiger Bausteine einen Gruppennamen (Klassennamen) und beschreiben die gemeinsamen Merkmale (Attribute und Operationen). Objekte sind Instanzen einer Klasse.

Schaltflächen haben mit Listen und Eingabefeldern eine Menge gemeinsam. So kann man diese zum Beispiel sehen und ihnen den Eingabefokus geben. Wesentliche Aspekte der Programmierung für Ein- und Ausgaben sind bei all diesen Bausteinen gleich. In der objektorientierten Systementwicklung ist man bestrebt, gemeinsame Merkmale (Attribute und Operationen) nur einmal zu programmieren, um Arbeitsaufwand zu sparen. Das einmal programmierte Merkmal soll aber in allen Bausteinen wiederverwendet werden. Dazu benutzt man den Mechanismus der Vererbung. Das bedeutet, man muss eine allgemeingültige Basisklasse schaffen und dort die gemeinsamen Merkmale programmieren. Das könnte für die oben genannten Bausteine zum Beispiel die Klasse Steuerelement (Control) sein. Das man für eine Schaltfläche noch einen visuellen Effekt beim betätigen benötigt, ist etwas Spezielles und gehört nicht zu den gemeinsamen Merkmalen. Ein solches spezielles Merkmal wird dann auch nicht in der Basisklasse Control sondern in einer speziellen Klasse, die zum Beispiel eben genau Button heißen könnte, programmiert. Jedoch die Masse an Merkmalen erbt die Schaltfläche von ihrer Basisklasse. Diese spezialisierten Klassen nennt der Fachmann auch Ableitungen. Umgangssprachlich lässt sich Vererbung mit „ist ein/ist eine“ ausdrücken. Für die Ableitungen Button, ListBox, Edit stellt die Basisklasse Control eine Verallgemeinerung (Generalisierung) dar.

Basisklassen sind oft schon vorhanden und enthalten häufig benötigte Merkmale. Diese zu benutzen (von diesen zu erben) spart Programmieraufwand.

Besonders dann, wenn der Benutzer einer Klasse nicht deren Entwickler ist, kann es wichtig sein, bestimmte interne Sachverhalte der Klasse vor versehentlich falscher Benutzung zu schützen. Dafür kennt die Objektorientierung das Konzept der Sichtbarkeit. Attributen und Operationen können zum Schutz vor unsachgemäßem Zugriff unterschiedliche Sichtbarkeiten zugewiesen werden. Man unterscheidet in der Theorie zwischen den Sichtbarkeiten public, package, protected und privat. Für den Anfang wollen wir erst einmal nur die Sichtbarkeiten public und protected unterscheiden. Wie deren Namen bereits verdeutlichen, heißt public (öffentlich), dass von außen zugegriffen werden darf und protected (geschützt), dass dieser Zugriff nicht erlaubt ist.

Objekte können zum Schutz bestimmte Merkmale (vor allem Eigenschaften, aber auch Verhalten) verbergen.

Um Komplexität zu beherrschen, kann man größere Dinge aus kleineren zusammenbauen. Dabei ist das Ganze verantwortlich für seine Einzelteile. Das ist nicht nur beim Programmieren so. Es verwundert also nicht, dass in einer objektorientierten Programmiersprache komplexe Klassen aus einfachen Klassen zusammengebaut werden können. Die Verantwortlichkeit kann man vereinfacht mit hat ausdrücken.

Komplexe Systeme bestehen aus einfachen Bausteinen.

Das Konzept der Nachrichten müssen wir aus zwei Blickwinkeln betrachten. Zum einen im Zusammenhang mit der oben genannten Kapselung. Es hat sich bewährt, vor allem Attribute vor dem direkten Zugriff zu schützen und das Schreiben oder Lesen von Attributen nur über den Aufruf von Operationen zu ermöglichen. Dieser Aufruf von Operationen bedeutet, dem betreffenden Objekt eine Nachricht zu senden. Das Objekt kann auf die Nachricht antworten; diese Antwort ist dann der Rückgabewert der Operation. Somit kommuniziert das System mit seinen Bausteinen über diese Nachrichten. Das der Aufruf von Operationen Nachricht und nicht Befehl genannt wird (obwohl er aussieht wie der Befehl in einer klassischen Programmiersprache), soll ausdrücken, dass der Empfänger entscheidet, was auf die Nachricht hin getan wird. So kann es durchaus sein, dass das System dem Objekt com3 zwar die Nachricht open sendet, dieses aber nicht darauf reagiert. Solch ein Verhalten muss kein Programmierfehler sein. Das Objekt com3 kann zum Beispiel festgestellt haben, dass gar kein Gerät angeschlossen ist und entscheidet für sich selbst, zur Sicherheit, den Port geschlossen zu halten, ohne erst mal um Genehmigung zu bitten.

Das System arbeitet mit seinen Bausteinen zusammen, indem es mit diesen Nachrichten austauscht. Der Empfänger einer Nachricht entscheidet was getan wird.

Manchmal ist es erforderlich, das Einzelteile direkt miteinander Nachrichten austauschen. Der „kleine Dienstweg“ sozusagen. Dabei besteht als wesentlicher Unterschied zur Aggregation, dass die Einzelteile nicht füreinander verantwortlich sind, sich aber kennen.

Bausteine können mit anderen Bausteinen in Beziehung stehen. Man kennt sich.

Unsere natürliche Sprache ist objektorientiert!

Wenn die Schaltfläche gedrückt wird, zeige die Hilfe an.
If the button is pressed then shows the help.
if button.isPressed then help.show
if ( button.isPressed() ) help.show();

Zum Vertiefen: eser-30-oop-v1.1.pdf

• UML
• zurück zur Übersicht