Ideen        zurück ]      [ Index ]     

Ueber Analogien

Objektorientiertes Programmieren wird oft mit Analogien eingeführt - normalerweise mit unverstandnenen Analogien: Laura Lemay (java in 21 Tagen) beispielsweise sagt beispielhaft für viele: Objekte der Programmierung sind wie (analog) Objekte im wirklichen Leben. Legosteine sind Objekte im wirklichen Leben, man kann sie zusammenstecken und daraus grössere Objekte machen. Man kann mit Legosteinen Autos bauen. Autos sind auch Objekte. Alle wirklichen Autos gehören in die Klasse "Auto" und sind mithin Instanzen der Klasse "Auto".

Dieses Reden ist doppelt heillos: Die wirklichen Autos sind darin nämlich auch Instanzen des Objektes "Auto", also scheint Klasse und Objekt dasselbe zu sein. Umgekehrt sind Beschreibungen von wirklichen Autos auch Instanzen der Beschreibung des Objektes "Auto".
Im Programm gibt es den Variablentyp "Auto" mit der Eigenschaftsdomäne "PKW, LKW". Das ist ein Objekt, aber die Variable ist das Objekt, nicht ein wirkliches Auto. Dann gibt es im Programm die Variable Auto mit der (zugewiesenen) Eigenschaft LKW. Das ist eine Instanz des Ojektes, aber sowohl das Objekt wie die Instanz sind im Programm, nicht auf der Strasse.

Die Variable Auto mit der Eigenschaft LKW ist eine Instanz des Objektes Auto, aber keine Instanz des Okjektes Fahrzeug, wenn "Fahrzeug die Klasse des Objektes Auto ist. Zwar vererben sich die Eigenschaften des Objektes Fahrzeug auf die des Objektes Auto, aber es sind zwei verschiedene Objekte, weil für das Objekt Auto mehr Bedingungen gelten.

Darin wird auch die Problematik des Ansatzes sichtbar. Man sollte möglichst kleine Objekte wählen: Dann müsste man natürlich "LKW" nicht als Eigenschaft von Auto nehmen, sondern als Objekt der Klasse "Auto". Und jede Eigenschaftsdomäne lässt sich in Objekte überführen: grosse LKW können LKW mit der Eigenschaft "gross" sein", sie können aber ebensogut Objekte "GLKW" oder "40-Tönner" sein. Und deutsche 40-Tönner sind eine Teilmenge der 40-Tönner, usw.

Eine bestimmte Analogie

Im wirklichen Leben unterscheide ich Symbole und Referent (Abbildungen und Abgebildetes). Das Wort "Auto" ist kein Auto, sondern ein Wort (Ce n' est pas une pipe).

Das Wort "Auto" verwende ich, wenn ich ein Auto meine und auch, wenn ich den Begriff "Auto" meine, also für das Auto, das ich zeichnen kann und für das Auto, das ich sprachlich bezeichnen kann. Das eine Auto ist konkret, das andere ist abstrakt. Sprachlich deute ich auf das Objekt, zeichnerisch auf eine Instanz. In der Zeigedefinition bringe ich die beiden zusammen, indem ich das Objekt anspreche und auf eine Instanz zeige.

Abstraktion heisst das Verhältnis zwischen Objekt und Instanz.

Autos kann ich klassifizieren. Ich kann sagen, die Autos bilden eine Klasse, die ich Auto nenne. Ich kann sagen, Autos gehören zur Klasse der Fahrzeuge. Das heisst, ich kann die Klasse so oder so benenen. Ich kann sagen, die zehnjährigen Schüler bilden ein Klasse. In diesen Fällen ordne ich Objekte einer Klasse zu.

Verallgemeinerung heisst das Verhältnis zwischen Objekt und Klasse.

Ich kann sagen, Autos sind Fahrzeuge, die mindestens 4 Räder und eine Karosserie haben. Ich kann sagen, Autos gehören zur Klasse der Fahrzeuge, die mindestens 4 Räder und eine Karroserie haben. In diesen Fäll nenne ich ein Kriterium, nach welchem ich die Zuordnung mache. Mit dieser Zurordnung definiere ich das Objekt (Auto), das ich im letztere Fall als Teilklasse der Klasse Fahrzeuge bezeichne.

Die wirklichen Autos kann ich auf einem Parkplatz gruppieren, indem ich sie von den Motorrädern getrennt aufstelle und die Teil mengen LKW und PKW zusätzlich getrennt aufstelle. Die wirklichen Autos sind Autos, keine Wörter (Ce n' est pas une pipe).

Pragmatik

Ich kann sagen: Autos sind Fahrzeuge - was natürlich für Lego-Autos nur sehr speziell zutrifft, sie sind Spielzeuge und mithin allenfalls Modelle von Autos im Sinne der Modelleisenbahn. Wirkliche Autos sind Fahrzeuge, aber nicht alle Fahrzeuge sind Autos. Unter der pragmatisch gegebenen Vereinbarung ist "Fahrzeug" auf der begrifflichen Ebene ein Oberbegriff von "Auto", weil alles, was für Fahrzeuge zutrifft, im Sinne der objektorientierten Vererbung auch für Autos zutrifft.

Klasse ist aber kein Oberbegriff von Schüler. Ich sage nicht, alle Schüler sind Klassen, aber nicht alle Klassen sind Schüler. Die Klasse ist etwas anderes als der Oberbegriff.

In meiner wirklichen Welt sind die Beschreibungen und das Beschriebene nicht nur unterschieden, sondern getrennt (Ce n' est pas une pipe). In der Welt der Programmierung sind die Verhältnisse sehr anders. Ein Programm ist ein Gegenstand, der zur Steuerung von programmgesteuerten Maschinen (Automaten) hergestellt wurde. Das Programm ist aber auch eine Beschreibung dieser Maschine. Deshalb ist jede Analogie zur wirklichen Welt zur Hälfte falsch.

Wenn ich das Programm als Beschreibung auffasse, werden pragmatisch gesehen Gegenstände aus der wirklichen Welt beschrieben, die man klassifizieren kann. Ich sage dann im Programm, es gibt "Autos" (Vereinbarung) und "meinAuto" hat ein "automatischesGetriebe" (Initierung/Zuweisung).

Wenn ich das Programm als Artefakt auffasse, kann ich dessen Variable-Typen als Objekte sehen und die Variablen als Instanzen. "Auto" ist dann ein Objekt und "meinAuto" eine Instanz.

Das Objekt wird konstitutiv durch einen "Konstruktor" erzeugt und nachfolgend (konsekutiv) mit Eigenschaften versehen

Wo ist die Analogie

Es geht darum, die Sprache als Analogie zu nehmen, nicht die Objekte der wirklichen Welt.

In Wirklichkeit geht es natürlich um das umgekehrte: die Analogie muss unser Wirklichkeitskonzept erläutern, nicht die Artefakte, die wir Programme nennen.


RESTE

Eine Klasse ist eine Menge von Entitäten mit einer die Klasse konstituerenden Eigenschaft. Ich habe eine Menge von Werkzeugen. Ich bilde Klassen: Eigentliche Werkzeuge und Maschinen. Dann habe ich zwei Mengen von Werkzeugen, wobei in einer Menge nur noch Werkzeuge sind, die mit toter Energie angetrieben werden. Ob eine Entität zu einer Klasse gehört oder nicht ist, ist davon abhängig, ob sie das Klassenzugehörigkeitskriterium erfüllt.

Wenn ich "Maschine" definiere, dann beschreibe ich eine Klasse von Werkzeugen - und/oder die Klassenkriterien.

Im Beispiel "Eine Maschine ist ein Werkzeug, das mit toter Energie angetrieben wird" ist "Maschine" zunächst ein "Ausdruck". Dann ist dieser Ausdruck ist ein "Begriff", weil er für eine "Definition" steht. Der Begriff "Maschine" ist semnatisch äquivalent mit dem Ausdruck "Werkzeug, das mit toter Energie angetrieben wird".

Umgangssprachlich sage ich unscharf, dass der Satz "Eine Maschine ist ein Werkzeug, das mit toter Energie angetrieben wird" eine Definition sei. Damit handle ich mir Probleme ein, weil unklar bleibt, welcher Teil des Satzes die Definition ist.

Formal kann ich sagen: "Maschine" =(semantisch äquivalent)= "Werkzeug, das mit toter Energie angetrieben wird". Der Ausdruck "Werkzeug, das mit toter Energie angetrieben wird" beschreibt eine Teilmenge der Werkzeuge, indem diese Werkzeugen eine bestimmte Eigenschaft zugeschrieben wird, die andere Werkzeuge nicht haben.

Die Definition ist pragmatisch, nicht semantisch.

Hintergrund: Formalismusstreit Gödel - Finsler und Semiotik

Ich unterscheide zwei Perspektiven: Pragmatik und Semantik. Semantik untersucht welche Wörter zu welchen Wörtern passen. Dazu muss ich kein Weltverständnis haben, sondern viele Texte. (Maschinelles Uebersetzen mit einem semantischen Lexikon (in welchem mittlerweile ganze Sätze abgelegt werden, wodurch auch klar wird, was ein Satz ist, was die Germanisten bisher nie sagen konnten)).

Pragmatik ist keine Sprach-, sondern eine Welt"wissenschaft" - dafür muss ich "in-der-Welt-sein" (aber nicht in der Welt von Herrn Heidegger). Es geht darum, dass ich verschiedene Gegenstände


Zur Dokumentation der unbedarften Sprache

Objektorientierte Programmierung ist das Modellieren von Objekten, die wie im echten Leben aus vielen kleineren Objekten bestehen. Diese Möglichkeit des Kombinierens von Objekten ist aber nur ein sehr kleiner Aspekt der objektorientierten Programmierung. Objektorientierte Programmierung bietet viele andere Konzepte und Merkmale, um Objekte einfacher und flexibler zu gestalten und zu benutzen. Das wichtigste Merkmal ist die Klasse.

Eine Klasse ist eine Sammlung aller Eigenschaften und Methoden der Objekte dieser Klasse und legt fest, wie diese zu erzeugen sind.

Wenn Sie ein Programm in einer objektorientierten Sprache schreiben, definieren Sie keine Objekte an sich. Sie definieren vielmehr Objektklassen.

Nehmen wir beispielsweise an, Sie haben eine Klasse namens Baum, die die Merkmale aller Bäume (haben Blätter und Wurzeln, wachsen, produzieren Chlorophyll) beschreibt. Die Baum-Klasse dient als abstraktes Modell für das Konzept eines Baums - die Hand ausstrecken und ihn anfassen, also mit ihm interagieren, oder ihn fällen - bedarf einer konkreten Instanz eines Baumes. Selbstverständlich können Sie viele Instanzen eines Baumes schaffen und jede Bauminstanz kann andere Merkmale haben (klein, groß, buschig, winterhart oder abfallend), ein Baum bleibt aber immer ein Baum (siehe Abb. 2.1).

Eine Instanz einer Klasse ist ein anderes Wort für ein tatsächliches Objekt. Während Klassen eine abstrakte Darstellung eines Objekts sind, ist eine Instanz dessen konkrete Darstellung.

Was genau ist also der Unterschied zwischen einer Instanz und einem Objekt? Eigentlich nichts. Objekt ist ein allgemeinerer Begriff, doch sind sowohl Instanzen als auch Objekte die konkrete Darstellung einer Klasse. In der objektorientierten Programmierung werden die Begriffe Instanz und Objekt meist gleichbedeutend verwendet. Eine Instanz eines Baumes und ein Baumobjekt sind das gleiche.

Wohin muss man die Hand wohl strecken, wenn man den Baum wirklich anfassen will, der als Java-Objekt existiert?

Objekt und Instanz werden als dasselbe bezeichnet. "Heillos" ist hier wohl ein recht mildes Wort.