Mit "Objekt" verbinde ich vor allem Gegenstand, objektiv und neuerdings objektorientierte Programmierung. Vielleicht ist es sinnvoll, wenn wir uns fragen, warum die objektorientierte Programmierung "objektorientiert" heisst. Ich gehe davon aus, dass dieser Name ganz unbewusst und naiv entstanden ist, dass wir aber jetzt - im Nachhinein - diese Programmierung dazu benützen können, zu verstehen, was wir mit Objekt genau meinen. Vielleicht siehst Du einen anderen Anfang?
So wie Du jetzt angefangen hast, lese ich Objekt als Synonym zu Gegenstand oder zu Ding. Ich glaube, dass wir den Ausdruck auch im Alltag gezielter verwenden. Mir scheint, ich spreche nur von Objekten, wenn ein bestimmter Kontext explizit gegeben ist, etwa würde ich von den Objekten einer Liegenschaftsverwaltung sprechen, nicht aber von den Gegenständen einer Liegenschaftsverwaltung. Daraus will ich etwas lernen.
Für unseren Dialog denke ich aber vor allem an die objektorientierte Programmierung als gegebener Kontext.
Wir könnten uns an diesem Beispiel mit der objektorientierten Terminologie - wie sie etwa im Buch "NeXTSTEP, Object-Oriented Programming and the Objective C Language, 1993" präsentiert wird -, vertraut machen und sehen, wie sie unser Hyperlexikon beeinflusst. Zu object ist beispielsweise vermerkt: "A programming unit that groups together a data structure (instance variables) and the operations (methods) that can use or affect that data" (233) und an anderer Stelle: "Likely, if you've ever tackled any kind of difficult programming problem, your design has included groups of functions that work on a particular kind of data - implicit "objects" without the language support. Object-oriented programming makes these function groups explicit and permits you to think in terms of the group, rather than its components. The only way to an objects data, the only interface, is through its methods" (5).
Wenn ich Dein obiges Beispiel von den Objekten einer Liegenschaftsverwaltung in dieser Hinsicht lese, dann frage ich nach den Methoden des Objektes, um die Daten im Sinne der (Liegenschafts)Verwaltung zu manipulieren.
Ich beginne aber gerne mit dem Vorschlag von Nextstep, denn ich zuerst in mein Verständnis übersetzen will:
"A programming unit" heisst "Ein Programm"
"that groups together" heisst .... ? Das verstehe ich eigentlich nicht. Als englisch-deutsch-Uebersetzung würde ich lesen: "das gruppiert" oder "eine Gruppe erzeugt". Aber ich kann mir nicht recht vorstellen, wie ein Programm ein Gruppe macht, resp. was das heissen soll.
".. a data structure (instance variables) and the operations (methods)" heisst "eine Datenstruktur und Operationen". Das sind zwei Begriffe, die wir wohl erläutern müssten. Ohne weiter nachzudenken sage ich: eine Datenstruktur ist ein Objekt.
"operations, that can use or affect that data" heisst "Operationen, die Daten verwenden oder betreffen". Ich unterstelle, dass Daten hier irgendwie auf die davor genannte Datenstruktur verweist, verstehe allerdings nicht recht wie.
Vielleicht würde ein Beispiel helfen?
Ein Objekt ist ein in sich geschlossener Teil eines Programms oder anders gesagt, ein Programm setzt sich aus Objekten zusammen. Es ist es wichtig, dass das, was in der OOP als Objekt bezeichnet wird, in der Programmiersprache referenziert werden kann. Wenn also in einem Programm von einem Objekt die Rede ist, dann ist damit gemeint, dass diese Einheit aus Methoden (oder Operationen) und Daten (oder Datenstrukturen) besteht. Zwar kann ich, so wie Du, sagen, dass eine Datenstruktur ein Objekt ist, aber hier ist gemeint, dass zur Datenstruktur Methoden gehören, mehr noch, dass die Datenstruktur durch die Methoden eingekapselt ist und nur via diese Methoden behandelt werden kann. Bestimmt die Datenstruktur den Zustand der Einheit so bestimmen die Methoden ihr Verhalten.
Das Beispiel, das NeXTSTEP verwendet, ist die Wasserversorgung eines Eigenheims. Stell Dir ein Objekt vor bestehend aus Methoden zum Starten und Stoppen des Wasserzuflusses, Setzen der Durchflussrate, Melden der in einer bestimmten Periode verwendeten Wassermenge und so weiter. Um diese Aufgaben auszuführen müsste das Objekt eine Datenstruktur haben um den Durchfluss aufzuzeichnen, die Durchflussrate zu ändern, die verbrauchte Wassermenge aufzuzeichnen und es müsste mit den entsprechenden Methoden bestückt sein. Vielleicht hilft es Dir, wenn Du das Beispiel und die Erläuterungen dazu im Original liest.
Dazu würde ich erneut Beispiele brauchen. Ich versuche also Dein Nextstep- Beispiel zu interpretieren:
Die Wasserversorgung eines Eigenheims, oder sagen wir - für einfache Gemüter wie mich - etwas praktischer und nachvollziehbar einfacher ein WC mit Wasser-Spülung. Der Spülkasten hat eine Spültaste und eine Uhr, die den Wasserverbrauch anzeigt. Ich kann die Taste drücken und danach ablesen, wieviel Wasser ich verbraucht habe.
Nun will ich mein WC mit dem Computer steuern und natürlich die Messwerte der Wasseruhr auch am Computer sehen. Also muss ich zunächst mein WC aufrüsten. Ich muss fernbedienbare Schalter einbauen und die Messuhr, die bisher die Umdrehungen eines Wasserrädchens direkt mechanisch - wie etwa der Kilometerzähler am Fahrrad - anzeigte, muss ein Signal erzeugen, dass ich im Computer auswerten kann.
Jetzt muss ich ein Computerprogramm schreiben. Ich kann - wie Du vorschlägst - sagen, dass das Programm bestimmte Aufgaben löst, aber im Moment des Programmierens muss ich bestimmte Aufgaben lösen: ich müsste ein Objekt sehen, eine Struktur und Methoden. Ich sehe also das Objekt WC-Spülung - das ist eine funktionale Bestimmung eines Systems, die im weiteren belanglos ist. Dann sehe ich die Struktur der WC-Spülung, das sind Wasserbehälter, Röhren, Schalter und Uhren. Dann sehe ich Methoden. Ich nehme hier nur eine einzelne Methode. Diese Methode ermöglicht es mir, den Wasserverbrauch zu begrenzen. Wenn 100 Liter Wasser verbraucht sind, stellt die Wasserzufuhr ab, und das WC kann nicht mehr gespühlt werden. Das ist nicht so unsinnig, wie es scheint, sondern eine kommerziell motivierte Methode, weil ich später mit anderen Methoden Geld verlange, damit wieder Wasser kommt. Hier genügt aber ein abgegrenzter Teil der Methode "Geld kassieren", der selbst eine Methode ist, nämlich "Wasserzufuhr begrenzen".
Bevor ich weiter interpretiere, werde ich Gewahr, dass ich am interpretieren bin. Ich frage deshalb, ob Du Deinen Text auch so lesen und paraphrasieren kannst und willst, oder ob Du die Sache anders siehst.
Generell scheint mir, ich wollte über die wirkliche Welt der Gegenstände etwas sagen und Du antwortest auf der Ebene der Programmiersprache. Meinst Du, dass man von Objekten nur in der Programmiersprache sinnvoll sprechen kann. Wäre es nicht überhaupt sinnvoll, von Objekten zu sprechen?
Ich zähle ein Programm ebenfalls zur wirklichen Welt der Gegenstände. Wenn ich für die Steuerung meines WC's den Computer einsetzen will, dann stelle ich die Steuerung als Gegenstand her. Ich meine allerdings nicht, dass man nur in der Programmiersprache sinnvoll über Objekte sprechen kann, aber seit wir bei der Herstellung der Steuerung von Objekten den Ausdruck Objekt programmatisch verwenden, kann ich nicht mehr gleich wie bis anhin über Objekte sprechen. Ich sehe also keine Objekte überhaupt sondern solche, worin die Verwendung des Ausdruckes in der OOP aufgehoben ist.
Vor diesem Hintergrund will ich nun aber gerne mit Dir über die wirkliche Welt der Gegenstände sprechen und die Ebene der Programmiersprache verlassen.
Ich habe in unserem Lexikon unter Objekt schon früher einen Versuch angefangen. Dabei schien mir das Wesentliche im Unterschied zwischen Objekt und Instanz zu liegen. Dieser Versuch ist aber eher sprachphilosophisch als an einer Programmiererfahrung orientiert. Ich glaube, dass sich darin zwei Welten zeigen und dass man eine aufwendige Brücke bauen muss, um sie zu verbinden. Falls Du mit "harzig" diese Kompliziertheit meinst, kann ich Dir nur zustimmen. Die praktische Vernunft der Ingenieure - ich denke beispielsweise an Thomas, erkenne sie aber ohne weiteres auch bei Marco - hat schon lange entschieden, dass die Technik nicht verstanden werden kann. Wenn wir es trotzdem versuchen, wäre es erstaunlich, wenn wir auf Anhieb gut fortkommen. Wir brauchen Musse.
Die Brücke müsste dergestalt sein, dass wir nicht nur feine Definitionen im Lexikon haben, sondern dass wir aufgrund dieses Wissens effizient programmieren können - oder eine effiziente Programmierumgebung spezifizieren können. Ich jedenfalls leide nach wie vor daran, dass ich weder mit Aion noch mit Nextstep arbeiten kann.
Bist Du bei Nextstep der Unterscheidung Objekt versus Instanz begegnet?
Und noch ein PS: Worin unterscheiden sich die Beispiele Mehrfamilienhaus und WC-Spülung eigentlich?
Deinem ersten, eher sprachphilosophisch ausgerichteten Versuch verdanken wir das Beispiel Mehrfamilienhaus. Ich vermute, das Beispiel drängte sich in sprachlicher Hinsicht im Sinne des Gegenstandes als Kaufvertrag auf. Das Beispiel WC-Spülung stammt indirekt aus der OOP - wobei die Ingenieure gerade nicht an eigentlichen Definitionen interessiert sind, und in ihren Beschreibungen der gegenständliche Bezug erst aufgedeckt werden muss. Das ist die zweite Seite des Zurückgehaltenwerdens. Den Unterschied zwischen den beiden Beispielen sehe ich spontan darin, dass im ersten Fall strukturelle Parameter, im zweiten Fall neben den strukturellen auch Prozessparameter interessieren. Im Beispiel Mehrfamilienhaus würde ich Objekte (nicht im kaufmännischen Sinn) erst dort ins Spiel bringen, wo ich sie verwalten müsste. Dann würde aber nicht die Gebäudestruktur im Vordergrund stehen, sondern die (Verwaltungs)Prozessstruktur. Trotzdem scheint mir Deine Unterscheidung Objekt - Instanz in diesem Beispiel gut dokumentiert.
Die Unterscheidung Objekt - Instanz ist in der OOP allgegenwärtig doch habe ich bisher noch nicht wirklich begriffen, was der gegenständliche Bezug ist. Es kommt mir vor, wie wenn ich - um in Deinem Bild der Brücke zu bleiben - auf beiden Seiten, der sprachlichen und der gegenstandspraktischen Grund suchen würde, um Pflöcke für den Brückenschalg einzugeschlagen.
Die Frage: "Was ist ein Objekt?" will als Antwort eine Definition. Wenn wir die Frage beantwortet haben, wissen wir, wie wir zu einer Definition gekommen sind. Wenn wir zuerst entscheiden, wie man definiert, können wir das Verfahren auf das "Objekt" anwenden und wissen dann, was ein Objekt ist. So sehe ich die wechselseitige Verknüpfung der beiden Fragen.
Ich wende mich jetzt der ersten Frage zu: Definitionen führen einen Oberbegriff und ein Kriterium ein. Ein Tiger ist in diesem Sinne eine Katze (Oberbegriff) mit gestreiftem Fell (Kriterium). Jetzt ist die Frage, welche Oberbegriffe weiterführen, respektive was "weiterführen" hier heissen könnte. Ich definiere Gegenstände (Objekte), um Ordnung in meine Erfahrung zu bringen. Das Grundprinzip ist die Klassifikation (Hierarchien) nach Verwandtschaften (Vererbung). Wenn ich Tiere und Pflanzen klassifiziert habe, weiss ich, dass Tiger katzenartiges Verhalten zeigen, und weil Katzen zu den Raubtieren gehören, und die Raubtiere zu den Säugetieren gehören, und die Säugetiere zu den Wirbeltieren gehören, weiss ich dass Tiger eine Wirbelsäule haben. Das ist, was Linne systematisches Wissen genannt hat. Ich würde das Ordnungswissen nennen, weil ich von systematischem Wissen mehr verlange, nämlich ein Wissen um die Funktionsweise eines Systems.
Deshalb erachte ich als "weiterführende" Begriffe, die ich beim Definieren suche, solche, die für Systeme stehen. Im exemplarischen Beispiel ist das Werkzeug ein potentielles System, weil es als Oberbegriff zu Automat, einem expliziten System, verwendet wird. Das Werkzeug ist funktional bestimmt, also aus einem Handlungszusammenhang heraus, es ist die oberste oder elementarste Stufe einer Definitionskette. Dass es ein System ist, zeigt sich nur in seinen Unterbegriffen, die in Definitionen nicht vorkommen. Daraus folgere ich, dass man vor jeder Definition sich entscheiden muss, ob man im Bereiche der Systeme definieren will, oder anders gesagt, ob man systemtheoretisch argumentieren will. Ich habe mich dafür entschieden, deshalb ist mir das Werkzeug als unentwickeltes System exemplarisch.
Tiger und Katzen sind natürlich auch Systeme, aber "natürliche", also solche, die ich nur erzeugen, aber nicht herstellen kann. Damit ist ein zweites Kriterium genannt: ich suche beim Definieren nach herstellbaren Systemen.
Schliesslich bewege ich mich beim Definieren immer in der Sprache, mache also - pragmatisch gesehen - Abbildungen von Referenten. Das Wort "Werkzeug" ist kein Werkzeug, the map ist not the territory. Meines Erachtens ist das der Ort der Uebung: sich bewusst halten, ob man von Abbildungen oder von Referenten der Abbildungen spricht. Im konventionelle Ingenieurswesen geht das relativ (!) leicht (obwohl Brecht fragen muss, ob wirklich die Könige das siebentorige Theben gebaut haben). In der Informatik ist die Unterscheidung zwischen Abbildung und Referent aber sehr subtil, weil die Referenten selbst sekundär lesbar, das abbilden oder beschreiben, was sie sind. Ein Programm beschreibt den Zustand des Automaten, auf welchem das Programm geladen ist.
Mein Vorschlag ist also, dass wir uns zuerst über das Definitionsverfahren einigen, und dann später unsere Argumente daran ausrichten oder prüfen.
Bisher haben wir mit dem Ausdruck Definition im Lexikon mehr verbunden als durch Klassifikation ersetzt wird. Die Differenz ist zum Teil im Ausdruck Erklärung aufgehoben, zum Teil kann der Ausdruck Erklärung erweitert werden und schliesslich kann ein Teil im Ausdruck Definition aufgehoben bleiben. Mein Vorschlag: Klassifikation (neu), Erklärung (verändert), Definition (verändert).
Der Ausdruck Objekt wird in dieser Redeweise implizit als Oberbegriff zu Artefakt und Nicht-Artefakt verwendet.
Ich kann jetzt sagen, dass im Definitionsverfahren weiterführende Begriffe systematische Erklärungen sind.
Vielleicht fällt Dir aber ein anderes Exemplar oder sackkonkretes Beispiel ein, das unser Denken in eine andere Richtung lenkt.
Ich glaube intuitiv, also vor jeder Reflexion, dass es sich um verschiedene "mentale" Operationen handelt, resp. um verschiedene Ebenen der Beschreibung.
Dazu fällt mir übrigens - nur nebenbei - wieder ein, woher ich die ganze Geschichte habe. In der Einleitung zur Sinnlichen Erkenntnis schreibt Holzkamp über das Definieren von Begriffen mit Oberbegriff und Kriterium. Dort habe ich mit meinen Formulierungen angefangen. Ich glaube, das fällt mir jetzt ein, weil mich der Ausdruck "Klasse" - nicht so sehr Schul-Klasse - an Holzkamp erinnert.
Immer noch im spotanen weilend würde ich sagen, dass Klassifikation des Verfahren bezeichnet, das zu Klassen führt. Was ist eine Klasse? In Deiner letzten Antwort schreibst Du: "Im Beispiel 'ein Tiger ist eine Katze mit gestreiftem Fell' ist 'Katze' die Klasse". Das ist doch auch eine verkürzte Redeweise. Ich lese Katze=Klasse und ahne, dass Du das nicht so gemeint hast.
Vielleicht ist es sinnvoll, die Begriffsarbeit im Lexikon zu machen und hier die Akzente anders zu legen. Bevor wir uns in der Definition der Definition verloren haben, wollten wir ja anhand unseres Projektes argumentieren. Nebenbei, es ist wahnsinnig, wie rasch ein Gespräck beliebig komliziert wird, wenn man es schreibt statt spricht.
Ich will also ein Neustart versuchen:
Unser Internet-Computer soll in etwa so funktionieren wie Dein Toolbook-Computer. Wenn ich ihn anstelle, will ich einen Browser (Objekt) sehen und im Browser will ich das Lexikon (Objekt) sehen. Das Lexikon enthält einen Index (Objekt) und beliebig viele Einträge (Objekt). Ein Eintrag ist ein Text (Objekt) mit einem mehr oder weniger festgelegten Format. Der Eintrag besteht aus Teil-Texten (Objekte). Ein Eintrag.Teiltext ist das Stichwort (Objekt). Die Buchstabenkette des Eintrag.Teiltext.Stichwort steht auch im Index. Im Index ist das Index.Stichwort ein Link auf den Eintrag.
Ich nehme hier ein Time-out: Glaubst Du, dass wir so zu einem Programm und zu einem Verständnis von Objekt kommen könnten?
Zu einem Programm kommen wir nur, wenn wir es herstellen. Ich beginne damit. Es müsste ja eigentlich spielend leicht zu bewerkstelligen sein, da wir schon ein funktionierendes Beispiel haben. Die Objekte werden von selbst ins Spiel kommen. Ich werde darüber berichten, wenn sie mir begegnen.