Platon und Objektorientierte Programmierung

BLOG: Bierologie

Weissbier & Wissenschaft
Bierologie

Wie nützlich es ist, auch mal über den Tellerrand der eigenen Profession hinauszuschauen, möcht ich heut am Beispiel Platons aufzeigen. Als Informatik-studierender Biologe helf ich wöchentlich anderen Studenten zum Nebenerwerb bei ihrer (Java-)Programmiererei. In einer der letzten Stunden ging mir eine kleine Funzel auf, und zwar ging’s um Objektorientierte Programmierung (OOP), und mir fiel auf, wie sehr die Grundidee dem Ideenbegriff Platons ähnelt! Wer über das eine Bescheid weiß, wird sehr schnell das andere verstehen – ein Grund dafür, soviel wie möglich wissen zu wollen!

Der Ideenbegriff bei Platon

Von Platon hörte ich das erste Mal, man glaubt es kaum, beim PC-Klassiker meiner Kindheit: “Indiana Jones and the Fate of Atlantis” – da sag noch einer, Computerspiele bilden nicht! Im Spiel ging es darum, einen verlorenen Dialog Platons wiederzufinden, in dem die genaue Position Atlantis’ genannt wird. Indiana Jones-typisch muss man da vor den Nazis ankommen, sonst bekommen die eine Energiequelle in die Hand, mit der sie den zweiten Weltkrieg gewinnen würden (die Story scheint plausibler als beim neusten Teil).

Leider kommt es im Spiel zu keinem Zeitpunkt zu einer Beschreibung der Lehren Platons, sein verlorener Dialog dient nur als MacGuffin-ähnliches Werkzeug, um Indy von Kontinent zu Kontinent zu jagen. Schauen wir uns also die Ideenlehre näher an – es lohnt sich!

Platons Rübe

Quelle: WikiMedia Commons, Benutzer Bibi Saint-Pol

Bei Platon bedeutet “Idee” nicht das, was wir heute darunter verstehen. Bei uns bedeutet Idee Einfall oder etwas ähnliches, während bei Platon Ideen etwas ganz anderes bedeuten. In Platons Philosophie gibt es durch die Sinne kein Wissen, denn die Sinne können täuschen. Von den Gegenständen selbst ist also nur Meinung möglich. Wo kommt dann Wissen her?

Wissen wird ermöglicht durch Einrichtungen, die bei Platon Ideen genannt werden. Jetzt wird’s wichtig: Ideen repräsentieren das reine Wesen, sie sind unveränderlich und unvergänglich. Ideen sind sinnlich nicht wahrnehmbar (schonmal die Idee eines Pferdes gesehen?) und existieren unabhängig von konkreten Einzeldingen.

Was bedeutet das genau? Wir haben die Idee eines Pferdes (4 Beine, Mähne, Fell einer oder mehrerer Farben etc.), und Fury draußen auf der Weide stellt ein Einzelding dieser Idee dar: 4 Beine, schwarze Mähne, schwarzes Fell. Fury kann die Idee eines Pferdes nicht beeinflussen, aber die Idee eines Pferdes beeinflusst sehr wohl Fury!

Klassen und Objekte bei OOP

Interessanterweise sind die Grundkonstrukte in der Objektorientierten Programmierung (OOP) sehr ähnlich zur Ideenlehre: Die Konstrukte heißen hier nur anders. In der OOP gibt’s Klassen und Objekte, und die Beziehung zwischen beiden ist die gleiche wie in der Ideenlehre: Klassen sind das “reine Wesen”, und Objekte sind die wirklichen Vertreter, erstellt an der Schablone der Klasse.

Ein Beispiel aus der Bioinformatik: Sagen wir, wir haben einen Haufen Gene, und von jedem so schöne Informationen wie Länge in Basenpaaren, passender Name aus irgendeiner Datenbank, komplette Nukleotidsequenz usw. Wir können jetzt eine Gen-Klasse definieren, in der wir all diese Informationen vorgeben (in anderen Worten: Alle Gene müssen Länge in Basenpaaren, Name etc. aufweisen). Dann können wir für jedes unserer Gene ein Objekt erschaffen, in welches wir die obengenannten Informationen eintragen. In Java sähe das so aus:

 public class Gene { 	String this.name; 	String this.sequence; 	int this.length; 	 	public Gene(String name, String sequence, int length) 	{ 		this.name = name; 		this.sequence = sequence; 		this.length = length; 	} 	. 	. 	. }

Und ein Beispielobjekt wäre:

Gene ura3 = new Gene("ura3", ">gi|162312575:c1387063-1385368 Schizosaccharomyces pombe 972h- chromosome I, complete sequence GAAACGGATTG...", 1696);

So wie Fury oben das Einzelding eines Pferdes darstellt, so ist hier ura3 ein Objekt aus der Klasse Gen. Das Objekt ura3 hat seinen eigenen Namen, seine eigene Sequenz, Länge der Sequenz etc., so wie es die Klasse Gen vorschreibt. Man sieht also, Platon’s Ideenlehre und OOP sind sich von den Grundkonstrukten sehr nah!

Fazit

“Was raucht der denn?” wird sich jetzt der eine oder andere fragen. Jedoch finde ich den Zusammenhang zwischen OOP und antiker Philosophie herrlich – wer Objektorientierte Programmierung vom Prinzip her nicht kapiert, dem wird vielleicht durch die Ideenlehre geholfen. Auch interessant zu sehen, wie sich Prinzipien in der Geschichte wiederholen. Meinem Studenten, der noch nie was von der Ideenlehre gehört hatte (und sowas ist Familienvater!) hat es sicherlich ganz bestimmt nicht geholfen…

Veröffentlicht von

Philipp hat einen Bachelor in Biologie, ein Graduate Certificate in IT und studiert momentan für seinen Master in IT in einem übertrieben großen Land voller Spinnen und Schafe. Für die Bierologie schreibt er zumeist über Biologie, Evolution und allem was an den Rändern der Gebiete noch so angeschwemmt wird.

19 Kommentare

  1. fast 🙂

    und was sind statische funktionen? und wie passen die noch esoterischeren interfaces in platons ideengebäude? oder sind interfaces die reine lehre? ganz zu schweigen von abstrakten klassen – den teilimplementierten klassen. 🙂

  2. Platon und (Experimental-)Physik

    Philipp Bayer schrieb (28. März 2011, 12:42):

    > In einer der letzten Stunden ging mir eine kleine Funzel auf, und zwar ging’s um Objektorientierte Programmierung (OOP), und mir fiel auf, wie sehr die Grundidee dem Ideenbegriff Platons ähnelt!

    > In der OOP gibt’s Klassen und Objekte, und die Beziehung zwischen beiden ist die gleiche wie in der Ideenlehre: Klassen sind das “reine Wesen”, und Objekte sind die wirklichen Vertreter, erstellt an der Schablone der Klasse.

    Eine vergleichbare Funzel ging der (Experimental-)Physik, und ganz besonders sicherlich Heisenberg, Bohr und von Neumann
    vor knapp 100 Jahren auf:

    In der (Experimental-)Physik gibt es
    (durch eine bestimmte Theorie definierte) Messgrößen bzw. Messoperatoren einerseits,
    und andererseits konkrete Messwerte, die durch Anwendung des jeweiligen Messoperators auf gegebene Beobachtungsdaten ermittelt worden sind, oder Erwartungswerte, deren zukünftige Ermittlung in Betracht gezogen wird.

    In größerem Maßstab gibt es einerseits Theorien, die (i.A. mehrere) Messoperatoren im Zusammenhang definieren (und sich mit den Konsequenzen dieser Zusammenhänge beschäftigen), und andererseits Modelle, die (i.A. mehrere) bestimmte Messwerte zusammenfassen und Erwartungswerte voraussagen.

    > […] Was bedeutet das genau? Wir haben die Idee eines Pferdes (4 Beine, Mähne, Fell einer oder mehrerer Farben etc.), und Fury draußen auf der Weide stellt ein Einzelding dieser Idee dar: 4 Beine, schwarze Mähne, schwarzes Fell. Fury kann die Idee eines Pferdes nicht beeinflussen, aber die Idee eines Pferdes beeinflusst sehr wohl Fury!

    Sehr richtig:
    ein konkreter erhaltener Messwert, ob so erwartet oder nicht (sondern überraschend), hat keinerlei “Rückwirkung” auf den Messoperator, mit dessen Hilfe er gewonnen wurde.

    (Trotzdem ist es natürlich i.A. stets interessant und richtig, weitere “neue” Messoperatoren zu erfinden und anzuwenden.)

    Deshalb kann man Leuten, die behaupten oder gar fordern, Theorien sollten “experimentell prüfbar/falsifizierbar” sein (und nicht etwa richtiger Weise: Modelle), nur empfehlen, auch mal ‘nen Kurs in OOP und/oder antiker Philosophie zu besuchen …

    > “Was raucht der denn?” wird sich jetzt der eine oder andere fragen.

  3. OOP ohne Klassen

    Klassen sind aber nicht zwingend notwendig für objektorientierte Programmierung. In JavaScript gibt es diese beispielsweise nicht.
    Und würde (bis auf die Einordnung des Konstruktors in die Klasse) dein Beispiel nicht auch mit einer Sprache ohne OOP-Funktionalität genauso funktionieren? Etwa in C mit einer struct “Gene”.

  4. Genauigkeit

    In der Philosophie wird Wert auf Exaktheit gelegt. In der Programmierung ist ebenfalls Genauigkeit gefragt. Daher sehe ich mich gezwungen wie mein Vorredner festzustellen: Fast. Und zwar noch viel grundsätzlicher 😉

    Im Beitrag hier ging es ausschließlich um die Beziehung Klasse-Objekt. Und für die passt der Vergleich mit viel Augen-zudrücken durchaus. Ob die Klasse jetzt (in Java) dieses oder jenes Interface implementiert ist für die Beziehung irrelevant. Die Klasse ist, wie sie ist in ihrer Gesamtheit. Statische Funktionen sind dabei auch kein Gegenargument. Zwar werden sie bei Java und vielen anderen Sprachen innerhalb der Klassendefinition notiert. Doch bereits im Java-Umfeld ist das nicht mehr so. Bei Scala wird strikt getrennt und alles statische landet nicht in der Klassendefinition, sondern in einem Singleton für jede Klasse.

    Ich bin (zum Glück) kein Philosoph. Aber ich erinner mich dunkel, dass die Ideen bei Platon eine reale Existenz haben. Bei Klassen ist das nicht in gleicher Weise der Fall. Klassen sind Schablonen, mehr nicht.

    Und ein letzter Punkt: Alles bisher gesagte bezieht sich wirklich nur auf Klassen und Objekte. Ob die Programmierung dabei objektorientiert ist oder nicht, das ist eine völlig andere Frage. Ein bekanntes Beispiel für objektorientierte Programmierung ohne einem Konzept für Klassen ist JavaScript. Für die Objektorientierung sind Klassen zwar ein häufig verwendetes Mittel. Sie sind aber in keiner Weise notwendig. Damit wären wir letztlich bei den Definitionen von OOP. Die kann aber jeder selber nachschlagen 😉

  5. Das will ich auch rauchen 😉

    Schöner Text. Das ist mal ne ungewöhnliche Sichtweise auf OOP 😉

    P.S.: Und das Spiel hab ich auf nem Atari gespielt.

  6. Mag ich!

    Danke, mag ich sehr, wenn meine hirn’schen Impulse auf synaptale Wildwechsel umgeleitet werden – fernab von irgend welchen konditionierten Autobahnen.

    Der dazu nötige, unscharfe Blick vermag durchaus das tiefere Verständnis über die Zusammenhänge der Dinge zu schärfen – wenn man sich nicht dagegen wehrt… 🙂

  7. @bruno jennrich: Ich wollt ja nur die Zusammenhänge zeigen 🙂 Von da an wandern beide Gebiete in komplett unterschiedliche Gefilde…

    @Frank Wappler: Sehr interessante Sichtweise!

    @bronte: Sicherlich geht das Beispiel auch ohne OOP, “früher” hab ich meine Bioinformatik auch komplett ohne OOP gemacht, dann hatte ich halt einfach mehrere Listen, oder z.B. eine Datei in den ich den ganzen Kram ausgelagert habt. Aber mit OOP ist das alles wesentlich eleganter 🙂

    @Lispl: Stimmt, die Ideen bei Platon haben eine reale Existenz. Bei OOP haben Klassen an sich keine Existenz, sie sind nur Schablonen. Natürlich kann man OOP und Ideenlehre nicht aufeinander pressen, da sind 2000 Jahre dazwischen, OOP wird in Programmiersprachen verwendet, die Ideenlehre um die Realität zu erklären.
    Natürlich haben beide Unterschiede, aber die Gemeinsamkeiten fand ich sehr interessant 🙂

  8. Die Existenz

    Gerade die Existenz der Ideen ist aber der zentraler Aspekt. Bei Platons Ideenlehre sind die Ideen das Wahre und Existierende, während das, was wir sonst so wahrnehmen, nichts als Schatten an einer Höhlenwand sind. Klassen kommt dagegen keinerlei vergleichbare Existenz zu – bis hin zu deren völliger Überflüssigkeit in manchen objektorientierten Sprachen. Bei Platons Ideenlehre sind die Ideen der zentrale Punkt, wie der Name schon sagt. In der objektorientierten Programmierung – ebenfalls nomen est omen – dreht sich dagegen alles um Objekte. Hier sind die Objekte das Wahre. Ich kann ein Objekt als ungenauen Klassentyp Fahrzeug ansprechen und trotzdem verhält es sich gemäß seiner ursprünglichen Definition exakt und korrekt, z. B. als Auto. Das Objekt weiß mehr als die Klasse mit der ich es anspreche. Und: Es weiß nie weniger als die Klasse, die als Schablone für die Erzeugung des Objekts diente. Ein Objekt ist also niemals nur ein flackerndes, ungenaues Abbild einer dahinterstehenden Klasse. Es ist mindestens gleich viel. Im Normalfall sogar mehr 😉

    In diesem Sinn kann der Vergleich sogar hinderlich für das Verständnis sein. Denn er ist zwar furchtbar eingängig und suggeriert dabei ein tieferes Verständnis. In Wahrheit aber schickt er einen auf eine falsche Fährte und erschwert es, das eigentliche Wesen der Objektorientierung zu erkennen. Denn das sind nicht Klassen. Sonst würde der ganze Spaß vermutlich auch anders heißen 😉

  9. Weniger bevormundet weniger …

    Lispl schrieb (29.03.2011 | 09:18):
    > Das Objekt weiß mehr als die Klasse mit der ich es anspreche. Und: Es weiß nie weniger als die Klasse, die als Schablone für die Erzeugung des Objekts diente.

    Ja: ein konkretes Objekt hat mehr konkretes “Wissen” (sozusagen) als seine Klassendefinition.

    Aber — Nein: die Klasse “weiß” (in einem allgemeinen Sinne) den gesamten “Wertebereich” aller möglichen konkreten Objekte, die auf der Klassendefinition beruhen könnten.

    Insbesondere (SWIV) könnten zwei völlig gleiche konkrete Objekte auf verschiedenen Klassendefinitionen beruhen; und, als gleiche Objekte, von dem Klassenunterschied nichts “wissen“.

  10. Vererbung und Duck-Typing

    Richtig. Es kann die Zugehörigkeit eines Objekts zu einer Klassendefinition festgestellt werden. Ob das aber die gesamte Klassendefinition des Objekts ist oder ob die jeweilige Klasse nur auf irgendeiner höheren Stufe der Vererbungshierarchie steht, das weiß nur und ausschließlich das Objekt selbst. Kurzum, den tatsächlichen Typ eines Objekts kennt nur das Objekt selbst mit Sicherheit. Das “Wahre” steckt damit in jedem konkreten Objekt und nicht in der Klasse, die sich niemals sicher sein kann, wie sie eigentlich in der Gesamtheit zu einem konkreten Objekt steht.

    Und das leitet direkt zum zweiten Punkt über: konkrete Objekte mit verschiedenen Klassendefinitionen. Das ist abermals etwas, was hochspezifisch für die Syntax und Semantik konkreter Programmiersprachen ist – nicht aber für objektorientierte Programmierung als solcher. Bei Sprachen ohne einem Konzept für Klassen wird die Zusammengehörigkeit von Objekten über Duck-Typing realisiert:

    “When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.”
    – James Whitcomb Riley

    Aus objektorientierter Sicht spricht absolut nichts gegen dieses Duck-Typing. Denn bei der Objektorientierung dreht sich eben alles um Objekte. Und nicht um Klassen.

    In diesem Sinn haben wir hier also ein Paradebeispiel für das, was ich vorhin schon gesagt habe. Platons Ideenlehre zur Veranschaulichung von Objektorientierung trägt nicht gerade zum tieferen Verständnis selbiger bei.

  11. Platonischer Zunder

    Lispl schrieb (29.03.2011 | 11:43):
    > Richtig. Es kann die Zugehörigkeit eines Objekts zu einer Klassendefinition festgestellt werden. Ob das aber die gesamte Klassendefinition des Objekts ist oder ob die jeweilige Klasse nur auf irgendeiner höheren Stufe der Vererbungshierarchie steht, das weiß nur und ausschließlich das Objekt selbst.

    Das mag ja “compiler-technisch” so sein, und von konkreten Sprach-Fällen habe ich diesbezüglich wenig Ahnung.
    Deswegen lieber ein Beispiel aus dem Bereich Messung – Messwert:

    Der Wert “5” könnte sowohl aus dem Wertebereich “Gewürfelte Augen (1 – 6)” kommen,
    oder (genau gleich) auch aus dem Wertebereich “Zahl gezogen bei 6 aus 49”,
    oder (genau gleich) auch aus dem Wertebereich “irgendeine natürliche Zahl”.

    Man sieht dem bloßen Wert (als “konkretes Objekt”) nicht den Wertebereich (nach “Klassendefintion”) an, in Bezug auf den er gefunden wurde.

    > “When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.”
    – James Whitcomb Riley

    Diese Aussage beruft sich ganz deutlich darauf, dass es eben viele verschiedene walk-, swim- bzw. quack-“Weisen” gibt, für die je nur eine bestimmte auf einen konkreten bird zutrifft bzw. zu ermitteln ist.

    Sie nutzt die Klassen(-Definitionen)
    “birds that walk”, “birds that swim” und “birds that quack”;
    unterstreicht also deren mehr oder weniger unabhängige und vorausgesetzte Existenz.

  12. Langsam wird es anstrengend. Was Compiler womöglich treiben ist unerheblich. Genau wie ihr Beispiel mit Messwerten. Wir reden von Objektorientierung. Nicht von Compilern und nicht von Messwerten. Ein Objekt ist etwas grundlegend anderes als ein Messwert. Insbesondere sieht man einem Objekt – und nur diesem – seinen tatsächlichen “Wertebereich” an, nicht aber einer Klasse. Sie können Wert und Wertebereich schlicht und ergreifend in keiner sinnvollen Weise auf Objekt und Klasse abbilden. Das sind völlig unterschiedliche Konzepte. Grundlegend.

    Ihr Versuch einer Analyse des Zitats ist ebenfalls nicht zielführend. Das Zitat dient lediglich der Veranschaulichung der Idee. Duck-Typing entspricht eher einem Clustering und eben keiner Klassifikation. Aber selbst das spielt keine explizite Rolle, sondern nur das Vorhandensein von gleichen Methoden bei der Verwendung.

  13. Das hab ich aber schon lange nicht mehr

    … “from scratch” gemacht; also nenn ich das Folgende mal betont “Pseudo-Code”:

    Include ZufallsZahlGenerator.hh // ZufallsZahl( Type, Min, Max );

    Class DiceThrow {
    Member: Integer Wert;
    Public:
    Constructor DiceThrow( String Vorgabe ) {

    Switch( Vorgabe ) {
    Case “eins”: Wert = 1;
    Case “zwei”: Wert = 2;

    Case “sechs”: Wert = 6;
    Case “valid”: Wert = ZufallsZahl( Integer, 1, 6 );
    Default: { Print( “Try again” ); Destruct; }
    };
    };

    OperatorBoolean Vergleich( DiceThrow b ) {
    Integer.Vergleich( a.Wert, b.Wert );
    };
    Destructor DiceThrow();
    }

    Dieser Klasse ist “anzusehen” (oder zumindest war es mein Ziel, das durch den Pseudo-Code auszudrücken), dass entsprechende Objekte nur im Wertebereich { 1, 2, … 6 } konstruierbar sind.

    Die Konstruktion konkreter Objekte würde etwa so erfolgen:

    DiceThrow mein_Wurf( “valid” );
    DiceThrow dein_Wurf( “valid” );
    DiceThrow man_darf_nochmal( “sechs” );

    Und ich würde gerne ausdrücken, dass mit diesen konkreten Objekten auch konkrete Vergleiche angestellt werden können, etwa:

    If( mein_Wurf.Wert kleiner_als dein_Wurf.Wert ) { … // du darfst anfangen };
    If( dein_Wurf.Wert =gleich= man_darf_nochmal.Wert ) { … // usw. };
    If( dein_Wurf.Wert =gleich= 1 ) { … // was auch immer die Spielregeln besagen};

    Einem einzelnen Objekt ist ein bestimmter einzelner Wert “anzusehen“; aber eben nicht der Wertebereich der gesamten Klasse.

    Lispl schrieb (29.03.2011 | 13:07):
    > Wir reden von Objektorientierung.

    Also? …

  14. Zwei Dinge:

    1. Dass Sie das Attribut “Wert” Ihrer Klasse so genannt haben, fasse ich als Eingeständnis dessen auf, was ich bereits sagte: Klassen und Objekte sind nicht auf die gleiche Weise Werte wie es primitive Datentypen – in Ihrem Fall eine Ganzzahl – sind. Ein Objekt Ihrer Klasse “DiceThrow” besteht aus mehr als dem Attribut “Wert” (sonst bräuchten Sie weder Klasse, noch Objekt, noch Objektorientierung). Unter anderem steht jedes Objekt in einer Vererbungshierarchie. Siehe dazu das bisher Gesagte. Insbesondere aber haben Sie eine Vergleichsmethode definiert. In Ihrer Definition wird das Attribut “Wert” als Vergleich herangezogen. Genau so gut könnte aber auch dessen Quadrat oder eine Zahl aus einem theoretisch unbegrenzten (praktisch durch den Speicher des Systems begrenzten) Bereich in der Methode für einen Vergleich genutzt werden. Das ist im Allgemeinen beliebig. Ein Objekt ist mehr als die primitiven Datentypen seiner Attribute.

    2. Ich habe nie behauptet, einem Objekt wäre der Wertebereich anzusehen. Im Gegenteil. Ich sagte und wiederhole es gerne: Werte und Wertbereich sind, so wie Sie die Begriffe verwenden, nicht auf Objekte und Klassen übertragbar und in deren Kontext vollkommen sinnfrei. Mit gutem Willen kann man zwar den Datentyp eines Objekts als “Wertebereich” interpretieren. Das wäre in Ihrem Beispiel dann “DiceThrow”. Bei dieser Interpretation greift jedoch alles, was ich bisher zu Vererbungshierarchien gesagt habe. Und über die Interpretation von Objekten als Menge primitiver Datentypen brauchen wir hoffentlich nicht mehr zu reden (siehe Punkt 1).

  15. Gut dosierte Anstrengungen …

    Lispl schrieb (31.03.2011 | 22:40):
    > 2. Ich habe nie behauptet, einem Objekt wäre der Wertebereich anzusehen.

    Ach so! — danke für die Klarstellung, denn: ich hatte die im Folgenden nochmals zitierte

    Bemerkung genau so aufgefasst:

    > > Lispl schrieb (29.03.2011 | 09:18):
    > > > Und: Es weiß nie weniger als die Klasse, die als Schablone für die Erzeugung des

    Objekts diente.

    bzw. Lispl … 29.03.2011 | 13:07:
    > > > Insbesondere sieht man einem Objekt – und nur diesem – seinen tatsächlichen

    “Wertebereich” an, nicht aber einer Klasse

    > Mit gutem Willen kann man zwar den Datentyp eines Objekts als “Wertebereich”

    interpretieren.

    Datentyp und Wertebereich (von instanzierbaren Objekten) hängen eng zusammen; ja, darauf

    wollte ich hinaus. (In wie fern das auch auf den Autor des Artikels, Philipp Bayer,

    zutrifft, könnte er ja mal bitte kundtun.)

    Ansonsten würde ich Typen bzw. Wertebereiche und Werte nicht unbedingt auf Daten

    einschränken;
    es gibt ja z.B. auch verschiedene Typen von (.. what’s the word? …) “Methoden”.
    Und ich würde lieber nicht sagen “ein bestimmter (Daten-)Typ ist ein bestimmter

    Wertebereich”, sondern eher “ein bestimmter (Daten-)Typ ist eine bestimmte Festlegung

    eines Wertebereiches”.

    Nachdem das (woran mir lag) nun vielleicht einigermaßen einverständlich ist, kann ich mich

    eigentlich überhaupt erst aud “das Drumherum” konzentrieren:

    > alles, was ich bisher zu Vererbungshierarchien gesagt habe […]
    > sonst bräuchten Sie weder Klasse, noch Objekt, noch Objektorientierung

    (sondern nur: Datentyp und … (?) … Konkretisierung? Instanzierung? Objekt?)

    Gut, aus dieser Perspektive:
    > > > Kurzum, den tatsächlichen Typ eines Objekts kennt nur das Objekt selbst mit

    Sicherheit.
    > > > nicht in der Klasse, die sich niemals sicher sein kann, wie sie eigentlich in der

    Gesamtheit zu einem konkreten Objekt steht.
    > > > Bei Sprachen ohne einem Konzept für Klassen wird die Zusammengehörigkeit von

    Objekten über Duck-Typing realisiert:
    > > > Sonst würde der ganze Spaß vermutlich auch anders heißen 😉

    (Nochmals: ich habe noch nicht z.B. durch nochmaliges Lesen des Artikels versucht

    herauszufinden, ob der Artikelautor das durchschaut und bedacht und gemeint hatte.)

    Ok — man kann sicher gewisse Datentypen als Komposit mehrerer verschiedener

    Datentyp-“Ahnen” auffassen.
    Und es mag sicher Sprachen geben, in denen man die Komposition nicht durch ausdrückliche

    Konstruktion einer “Nachkommen”-Klasse formulieren muss, sondern z.B. vielleicht
    “bloß durch Hinschreiben der Ahnen beim Instanzieren, für jede Instanz einzeln und i.A.

    verschieden”.

    Das entspricht m.E. trotzdem recht deutlich dem Konzept mehrerer miteinander kompatibler

    Messgrößen, mit einem entsprechenden Werte-Tupel für jeden Versuch.
    (Wenn ich schreibe “m.E.”, dann ist natürlich zu bedenken: When all you have is a hammer,

    everything starts to look like a nail …)

    > Ein Objekt ist mehr als die primitiven Datentypen seiner Attribute.
    Sicher — nicht zuletzt deshalb auch die obige Bemerkung zu “Methoden” …

  16. > Und es mag sicher Sprachen geben, in denen man
    > die Komposition nicht durch ausdrückliche
    > Konstruktion einer “Nachkommen”-Klasse formulieren
    > muss, sondern z.B. vielleicht “bloß durch Hinschreiben
    > der Ahnen beim Instanzieren, für jede Instanz einzeln
    > und i.A. verschieden”.

    Solche Sprachen gibt es tatsächlich. Scala erlaubt es z. B. “Traits” (Interfaces) bei der Instanziierung eines Objekts “beizumischen”. Bei Scala gibt es zwar Klassen, aber eben nicht bei jeder objektorientierten Sprache. Das ist nach wie vor ein grundlegendes Problem. Aber selbst mit Klassen bleibt die Sache mit der Vererbungshierarchie. Worauf ich hinaus will – nämlich deren offenes Ende – verdeutliche ich einfach am besten mit einem Beispiel:

    Klasse: Fahrzeug
    – davon abgeleitet:
    Klassen: Auto, Fahrrad, Schiff
    – von Schiff abgeleitet:
    Klassen: Fischerboot, Dampfer, Schnellboot

    Bei der OOP typisch ist, dass die Elternklassen keine Ahnung von den abgeleiteten Klassen haben (was gewollt und sehr nützlich ist). Eine Klasse Schiff kennt also die Klasse Fahrzeug und weiß, dass jedes Schiff-Objekt auch ein Fahrzeug ist. Sie hat aber keine Ahnung von Fischerbooten, Dampfern und Schnellbooten. Aber selbst die Fischerboot-, Dampfer- und Schnellboot-Klassen wissen nicht, ob sie dem Datentyp eines Objekts exakt entsprechen oder auch nur eine Elternklasse des tatsächlichen Typs sind. Was tatsächlich der Fall ist, das weiß nur und ausschließlich das jeweilige Objekt. Das ist der gesamte Punkt mit der Information und dem “Wissen”.

    Daher die Aussage, dass Objekte eben keine mit Verlust behafteten Schattenbilder der Klassen sind, sondern im Gegenteil echt mehr über ihre eigene Identität wissen. Und diese Konstellation – die Schattenbilder sind das Echte, Wahre und die Ideen nur einfache Schablonen – ist mit Platons Ideenlehre nicht vereinbarbar.

  17. Ich befinde michs eit zwei Wochen im Fernstudium mit dem Thema Softwareentwicklung. In dieser Woche ist nun das Thema OOP dran und ich muss sagen, die Lehrbücher sind extrem trocken geschrieben. Zum Glück gibt es Youtube und so tolle Blogs wie deiner der wirkllich hilfreich ist.

    Vielen Dank und beste Grüße

  18. Die Verwandtschaft zwischen Platons Ideenlehre und der OOP sah ich in der Vergangenheit auch bereits schon und gehe sogar noch einen Schritt weiter: Die Server sind das Reich der Ideen, das sich mit PHP modellieren lässt und die Anfrage des Browsers (als Welt der instaniierten Erscheinung) letztlich die Spielwiese der darzustellenden Objekte.

Schreibe einen Kommentar