Also, was hat Alan Kay wirklich mit dem Begriff "objektorientiert" gemeint?

Berichten zufolge ist Alan Kay der Erfinder des Begriffs "objektorientiert". Und er wird oft zitiert, dass das, was wir heute OO nennen, nicht das ist, was er meinte.

Ich habe das zum Beispiel gerade bei Google gefunden:

Ich habe mir den Begriff "objektorientiert" ausgedacht und kann Ihnen sagen, dass ich C ++ nicht im Sinn hatte

- Alan Kay, OOPSLA '97

Ich erinnere mich vage hören etwas ziemlich aufschlussreich über das, was er hat meine. Etwas in der Art von "Message Passing".

Weißt du was er meinte? Können Sie näher erläutern, was er meinte und inwiefern es sich von dem heutigen OO unterscheidet? Bitte teilen Sie einige Referenzen mit, wenn Sie welche haben.

Vielen Dank.

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Datum: Mi, 23 Jul 2003 09:33:31 -0800 An: Stefan Ram [aus Datenschutzgründen entfernt] Von: Alan Kay [aus Datenschutzgründen entfernt] Betreff: Betreff: Erläuterung von "objektorientiert"

Hallo Stefan -

Entschuldigung für die Verspätung, aber ich war im Urlaub.

Um 6:27 PM +0200 17.07.03 schrieb Stefan Ram:

Lieber Dr. Kay,

Ich hätte gerne ein verbindliches Wort zum Begriff "objektorientierte Programmierung" für meine Tutorial-Seite zu diesem Thema. Die einzigen zwei Quellen, die ich als "maßgeblich" betrachte, sind die International Standards Organization, die "objektorientiert" in "ISO / IEC 2382-15" definiert, und Sie, weil Sie diesen Begriff, wie sie sagen, geprägt haben.

Ich bin mir ziemlich sicher, dass ich es getan habe.

Leider ist es schwierig, eine Webseite oder Quelle mit Ihrer Definition oder Beschreibung dieses Begriffs zu finden. Es gibt verschiedene Berichte darüber, was Sie in dieser Hinsicht gesagt haben könnten (wie "Vererbung, Polymorphismus und Einkapselung"), aber dies sind keine Quellen aus erster Hand. Mir ist auch bewusst, dass Sie später mehr Wert auf "Messaging" legen - aber ich würde immer noch gerne etwas über "objektorientiert" erfahren.

Für die Aufzeichnungen, meine Tutorial-Seite und weitere Verbreitung und Veröffentlichung können Sie bitte erklären:

Wann und wo wurde der Begriff "objektorientiert" zuerst verwendet?

Irgendwann nach dem 66. November in Utah, als ich, beeinflusst von Sketchpad, Simula, dem Design für das ARPAnet, den Burroughs B5000 und meinem Hintergrund in Biologie und Mathematik, an eine Architektur für die Programmierung dachte. Es war wahrscheinlich im Jahr 1967, als mich jemand fragte, was ich tue, und ich sagte: "Es ist objektorientierte Programmierung".

Die ursprüngliche Konzeption hatte die folgenden Teile.

• Ich dachte an Objekte, die wie biologische Zellen und / oder einzelne Computer in einem Netzwerk sind und nur mit Nachrichten kommunizieren können (Messaging stand also am Anfang - es dauerte eine Weile, bis ich herausgefunden hatte, wie Messaging in einer Programmiersprache effizient genug ist, um zu funktionieren nützlich sein).

• Ich wollte Daten loswerden. Der B5000 hat dies dank seiner fast unglaublichen HW-Architektur beinahe geschafft. Ich erkannte, dass die Metapher für die Zelle / den gesamten Computer keine Daten mehr enthält und dass "<-" nur ein weiteres Nachrichtentoken ist (es dauerte eine Weile, bis ich mir das überlegte, weil ich all diese Symbole wirklich als Namen für diese Symbole angesehen hatte Funktionen und Verfahren.

• Durch meinen mathematischen Hintergrund wurde mir klar, dass mit jedem Objekt mehrere Algebren verknüpft sein könnten und dass es Familien von diesen geben könnte, und dass diese sehr, sehr nützlich wären. Der Begriff "Polymorphismus" wurde viel später auferlegt (ich denke von Peter Wegner) und ist nicht ganz gültig, da er wirklich aus der Nomenklatur der Funktionen stammt und ich ziemlich viel mehr als Funktionen wollte. Ich habe mir einen Begriff "Generizität" ausgedacht, um mit generischen Verhaltensweisen in einer quasi-algebraischen Form umzugehen.

• Mir hat nicht gefallen, wie Simula I oder Simula 67 geerbt haben (obwohl ich dachte, Nygaard und Dahl wären nur großartige Denker und Designer). Deshalb habe ich beschlossen, die Vererbung als integrierte Funktion wegzulassen, bis ich sie besser verstanden habe.

Meine ursprünglichen Experimente mit dieser Architektur wurden mit einem Modell durchgeführt, das ich von van Wijngaarten und Wirths "Generalization of Algol" und Wirths Euler adaptiert hatte. Beide waren eher LISP-artig, jedoch mit einer konventionelleren lesbaren Syntax. Ich verstand damals die Monster-LISP-Idee von greifbarer Metasprache nicht, kam aber den Ideen über erweiterbare Sprachen aus verschiedenen Quellen, einschließlich Irons IMP, ein Stück näher.

Die zweite Phase bestand darin, LISP endlich zu verstehen und dieses Verständnis dann zu nutzen, um viel schönere und kleinere, leistungsfähigere und später gebundene Unterstrukturen zu erstellen. Dave Fischers Abschlussarbeit wurde im "McCarthy" -Stil gemacht und seine Ideen zu erweiterbaren Kontrollstrukturen waren sehr hilfreich. Ein weiterer großer Einfluss zu dieser Zeit war Carl Hewitts PLANNER (der nie die Anerkennung erhalten hat, die er verdient, wenn man bedenkt, wie gut und wie früh er Prolog antizipieren konnte).

Das ursprüngliche Smalltalk bei Xerox PARC ist aus dem oben Gesagten hervorgegangen. Die folgenden Smalltalks werden am Ende des Kapitels "Geschichte" beanstandet: Sie sind in Richtung Simula zurückgefallen und haben die Verlängerungsmechanismen nicht durch sicherere ersetzt, die bei weitem nicht so nützlich waren.

Was bedeutet für Sie "objektorientierte [Programmierung]"? (Es ist keine Tutorial-ähnliche Einführung erforderlich, nur eine kurze Erklärung [wie "Programmieren mit Vererbung, Polymorphismus und Kapselung"] in Bezug auf andere Konzepte für einen Leser, der mit ihnen vertraut ist, wenn möglich. Außerdem ist es nicht erforderlich, "Objekt" zu erklären ", weil ich bereits Quellen mit Ihrer Erklärung von" object "aus" Early History of Smalltalk "habe.)

(Ich bin nicht gegen Typen, aber ich kenne keine Typensysteme, die keine völligen Schmerzen bereiten. Deshalb mag ich dynamisches Tippen immer noch.)

OOP bedeutet für mich nur Nachrichtenübermittlung, lokale Aufbewahrung und Schutz sowie das Verstecken von staatlichen Prozessen und extrem spätes Binden aller Dinge. Dies kann in Smalltalk und in LISP erfolgen. Es gibt möglicherweise andere Systeme, in denen dies möglich ist, aber ich kenne sie nicht.

Eines der Dinge, die ich hätte erwähnen sollen, ist, dass es zwei Hauptpfade gab, die von Simula katalysiert wurden. Der erste (nur aus Versehen) war der von mir eingeschlagene Bio / Net-Weg, bei dem keine Daten verarbeitet wurden. Der andere, der etwas später als Untersuchungsgegenstand kam, waren abstrakte Datentypen, und dies brachte viel mehr Spielraum.

Wenn wir uns die ganze Geschichte ansehen, sehen wir, dass das Proto-OOP-Zeug mit ADT begann, eine kleine Abzweigung zu dem hatte, was ich "Objekte" nannte - das führte zu Smalltalk usw. -, aber nach der kleinen Abzweigung, dem Das CS-Establishment tat ADT so ziemlich und wollte am Paradigma der Datenprozedur festhalten. Historisch gesehen lohnt sich ein Blick auf das USAF-Burroughs-220-Dateisystem (das ich in der Smalltalk-Geschichte beschrieben habe), die frühen Arbeiten von Doug Ross am MIT (AED und früher), in denen er die Einbettung von Prozedurzeigern in Datenstrukturen befürwortete (Sketchpad) vollständiger Polymorphismus - wo z. B. der gleiche Versatz in seiner Datenstruktur "Anzeige" bedeutete und es einen Zeiger auf die entsprechende Routine für den Typ des Objekts geben würde, das die Struktur darstellt, usw., und die Burroughs B5000, Ihre Programmreferenztabellen waren echte "große Objekte" und enthielten Zeiger sowohl auf "Daten" als auch auf "Prozeduren", konnten aber oft das Richtige tun, wenn sie versuchten, Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren. konnte aber oft das Richtige tun, wenn versucht wurde, Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren. konnte aber oft das Richtige tun, wenn versucht wurde, nach Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Problem, das ich mit meinen frühen Utah-Sachen löste, war das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Abhandlung mit dem Titel "Dataless Programming", und kurz darauf schrieb John Reynolds eine ebenso raffinierte Abhandlung mit dem Titel "Gedanken" (glaube ich 1970), in der er dies unter Verwendung der Lamda zeigte Ausdrücke auf die richtige Art und Weise würden es ermöglichen, Daten durch Prozeduren zu abstrahieren.

Die Leute, die Objekte als Nicht-Daten mochten, waren zahlenmäßig kleiner und schlossen mich, Carl Hewitt, Dave Reed und einige andere ein - so ziemlich alle dieser Gruppe gehörten der ARPA-Gemeinschaft an und waren auf die eine oder andere Weise in die ARPA involviert Design von ARPAnet → Internet, bei dem die Grundeinheit der Berechnung ein ganzer Computer war. Aber nur um zu zeigen, wie hartnäckig eine Idee sein kann, gab es in den siebziger und achtziger Jahren viele Menschen, die versuchten, mit "Remote Procedure Call" auszukommen, anstatt über Objekte und Nachrichten nachzudenken. Sic Transit Gloria Mundi.

Prost,

Alan Kay

Das meiste, wenn nicht alles, was Alan Kay mit Objektorientierung meinte, ist in der Smalltalk-Sprache enthalten.

Außerdem aus http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay hat argumentiert, dass die Weitergabe von Nachrichten in OOP wichtiger ist als Objekte, und dass Objekte selbst häufig überbetont werden. Das Programmiermodell für live verteilte Objekte baut auf dieser Beobachtung auf. Es verwendet das Konzept eines verteilten Datenflusses, um das Verhalten eines komplexen verteilten Systems anhand von Nachrichtenmustern zu charakterisieren. Dabei werden Spezifikationen auf hoher Ebene im funktionalen Stil verwendet.

Das meiste, wenn nicht alles, was Alan Kay unter Objektorientierung versteht, ist in der Smalltalk-Sprache enthalten.

"Wir haben bei PARC nicht einmal die ganze Idee umgesetzt. Viele der Ideen von Carl Hewitt's Schauspielern, die durch das ursprüngliche Smalltalk ausgelöst wurden, entsprachen eher dem Geist von OOP als den nachfolgenden Smalltalks. Bedeutende Teile von Erlang ähneln eher einer echten OOP-Sprache das aktuelle Smalltalk und sicherlich die C-basierten Sprachen, die mit "OOP paint" gemalt wurden. "

Entnommen aus Alan Kays Kommentar bei:

http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/

Einer der wichtigsten Punkte, die ich bei der Verfolgung der Arbeiten von Alan Kay und anderen wie Jim Coplien aufgegriffen habe, ist, dass es bei einer echten "objektorientierten" Programmierung darum geht, Computer und Software im Sinne von MENSCHLICHEN / BENUTZER-Mentalmodellen zu modellieren, anstatt zu sein nur ein Werkzeug für PROGRAMMIERER.

Ich verstehe, dass Alans Vision von OOP darin bestand, den Computer zu einem Werkzeug zu machen, mit dem ein menschlicher Benutzer alles machen kann, was er will: Die volle Leistungsfähigkeit des Computers wird dem Endbenutzer durch ein intuitives interaktives Modell direkt zugänglich gemacht. Ich sollte in der Lage sein, Laufzeitobjekte und Interaktionen DIREKT anzuzeigen und zu formen, nicht nur durch Code.

Hier ist ein Beitrag über meine Pläne, eine Version davon in JavaScript als Proof-of-Concept zu versuchen: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Aus der Perspektive der Softwareentwicklung / -programmierung spricht Jim Coplien darüber, wie Code dem mentalen Modell des Benutzers ähneln kann und SOLLTE. Das heißt, der Code liest sich so, wie er von einer Person, die ihr Verhalten beschreibt, klingt. Dies wird größtenteils durch das Denken in OBJEKTEN und nicht in KLASSEN und TYPEN erreicht. Das Verhalten wird anhand der von Objekten gespielten ROLES beschrieben, nicht als Teil der Definition der IDENTITÄT eines Objekts. Sie sollten in der Lage sein, Interaktionen anhand von Begriffen von Objekten zu modellieren, die durch die Rolle identifiziert werden, die sie in einer Interaktion spielen. So funktionieren menschliche mentale Modelle: Kellner, Kunde, Kassierer, Quellkonto, Zielkonto, ... Dies sind ROLES, nicht TYPES, und Sie möchten in der Lage sein, Methoden für jedes Objekt zu definieren, das gerade diese Rolle spielt ",