it-swarm-eu.dev

Was * meinte * Alan Kay wirklich mit dem Begriff "objektorientiert"?

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.

Zum Beispiel habe ich das gerade bei Google gefunden:

Ich habe mir den Begriff "objektorientiert" ausgedacht und kann Ihnen sagen, dass ich nicht an C++ gedacht habe

- Alan Kay, OOPSLA '97

Ich erinnere mich vage, etwas ziemlich Aufschlussreiches darüber gehört zu haben, was er tat meinte. Etwas in der Art von "Message Passing".

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

Vielen Dank.

104
Charlie Flowers

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


Datum: Mi, 23. Juli 2003 09:33:31 -0800 An: Stefan Ram [aus Datenschutzgründen entfernt] Von: Alan Kay [aus Datenschutzgründen entfernt] Betreff: Betreff: Klarstellung 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 maßgebliches 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 in "ISO/IEC 2382-15" "objektorientiert" definiert, und Sie, weil Sie, wie sie sagen, diesen Begriff 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 mehrere Berichte darüber, was Sie diesbezüglich 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" wissen.

Für die Aufzeichnungen, meine Tutorial-Seite und die 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 unter dem Einfluss 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 davon 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 kam also ganz am Anfang - es dauerte eine Weile, bis man wusste, wie man Messaging in einer Programmiersprache effizient genug macht, um dies zu tun nützlich sein).

  • Ich wollte Daten loswerden. Der B5000 hat dies fast durch seine fast unglaubliche HW-Architektur erreicht. Ich erkannte, dass die Metapher für die Zelle/den gesamten Computer Daten entfernen würde und dass "<-" nur ein weiteres Nachrichtentoken sein würde (es dauerte eine ganze Weile, bis ich mir das überlegt hatte, weil ich all diese Symbole wirklich als Namen für angesehen hatte Funktionen und Verfahren.

  • Durch meinen mathematischen Hintergrund wurde mir klar, dass jedem Objekt mehrere Algebren zugeordnet sein können und dass es Familien davon geben kann und dass diese sehr, sehr nützlich sind. Der Begriff "Polymorphismus" wurde viel später eingeführt (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.

  • Ich mochte die Art und Weise, wie Simula I oder Simula 67 vererbten, nicht (obwohl ich dachte, Nygaard und Dahl seien 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 aus van Wijngaartens und Wirths "Generalization of ALGOL" und Wirths Euler adaptiert habe. Beide waren eher LISP-ähnlich, aber mit einer konventionelleren lesbaren Syntax. Ich habe damals die Monster-LISP-Idee einer greifbaren Metasprache nicht verstanden, bin aber den Ideen zu erweiterbaren Sprachen, die aus verschiedenen Quellen stammen, einschließlich Irons 'IMP, ziemlich nahe gekommen.

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ät gebundene Unterstrukturen zu erstellen. Dave Fischers These wurde im "McCarthy" -Stil verfasst 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 nachfolgenden Smalltalks werden am Ende des Kapitels "Geschichte" beanstandet: Sie sind in Richtung Simula zurückgefallen und haben die Erweiterungsmechanismen nicht durch sicherere ersetzt, die bei weitem nicht so nützlich waren.

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

(Ich bin nicht gegen Typen, aber ich kenne keine Typsysteme, die kein völliger Schmerz sind, deshalb mag ich immer noch dynamisches Tippen.)

OOP bedeutet für mich nur Messaging, lokale Aufbewahrung und Schutz sowie das Verstecken von Staatsprozessen und die extreme Spätbindung aller Dinge. Dies kann in Smalltalk und in LISP erfolgen. Es gibt möglicherweise andere Systeme, in denen dies möglich ist, aber ich bin mir ihrer nicht bewusst.

[Außerdem] Eines der Dinge, die ich hätte erwähnen sollen, ist, dass es zwei Hauptpfade gab, die von Simula katalysiert wurden. Die erste (nur aus Versehen) war die Bio/Net-Route ohne Datenverfahren, die ich eingeschlagen habe. Der andere, der etwas später als Untersuchungsgegenstand kam, waren abstrakte Datentypen, und dies wurde viel spielerischer.

Wenn wir uns die gesamte Geschichte ansehen, sehen wir, dass das Proto-OOP-Zeug mit ADT begann und eine kleine Abzweigung zu dem hatte, was ich "Objekte" nannte - was zu Smalltalk usw. führte -, aber nach der kleinen Abzweigung die Die CS-Einrichtung hat ADT so ziemlich durchgeführt und wollte sich an das Datenprozedur-Paradigma halten. Historisch gesehen lohnt es sich, das USAF Burroughs 220-Dateisystem (das ich in der Smalltalk-Geschichte beschrieben habe) zu betrachten, das frühe Werk von Doug Ross unter MIT (AED und früher)), in dem er das Einbettungsverfahren befürwortete Zeiger in Datenstrukturen, Sketchpad (das einen vollständigen Polymorphismus aufwies - wobei z. B. der gleiche Versatz in seiner Datenstruktur "Anzeige" bedeutete und es einen Zeiger auf die entsprechende Routine für den Objekttyp geben würde, den diese Struktur usw. darstellte, und das Burroughs B5000, dessen Programmreferenztabellen echte "große Objekte" waren und Zeiger sowohl auf "Daten" als auch auf "Prozeduren" enthielten, aber oft das Richtige tun konnten, wenn sie versuchten, Daten zu suchen und einen Prozedurzeiger zu finden. Und das allererste Probleme, die ich mit meinen frühen Sachen in Utah gelöst habe, waren das "Verschwinden von Daten", bei dem nur Methoden und Objekte verwendet wurden. Ende der 60er Jahre (glaube ich) schrieb Bob Balzer eine ziemlich raffinierte Arbeit mit dem Titel "Dataless Programming", und kurz danach schrieb John Reynolds ein ebenso geschicktes Papier "Ged anken "(1970, glaube ich), in dem er zeigte, dass die richtige Verwendung der Lamda-Ausdrücke die Abstraktion von Daten durch Prozeduren ermöglichen würde.

Die Leute, die Objekte als Nicht-Daten mochten, waren kleiner und schlossen mich, Carl Hewitt, Dave Reed und einige andere ein - so ziemlich alle aus dieser Gruppe stammten aus der ARPA Community und waren auf die eine oder andere Weise am Design von ARPAnet → Internet beteiligt, bei dem die grundlegende Recheneinheit ein ganzer Computer war. Aber nur um zu zeigen, wie hartnäckig eine Idee in den siebziger und achtziger Jahren bleiben kann, gab es viele Menschen, die versuchte mit "Remote Procedure Call" auszukommen, anstatt über Objekte und Nachrichten nachzudenken. Sic Transit Gloria Mundi.

Prost,

Alan Kay

90
Manoj

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

Auch von http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay hat argumentiert, dass das Weiterleiten von Nachrichten wichtiger ist als Objekte in OOP und dass Objekte selbst häufig überbetont werden. Das Live-Programmiermodell für verteilte Objekte baut auf dieser Beobachtung auf. Es verwendet das Konzept eines verteilten Datenflusses, um das Verhalten eines komplexen verteilten Systems in Bezug auf Nachrichtenmuster unter Verwendung allgemeiner Spezifikationen im funktionalen Stil zu charakterisieren.
23
Mark Cidade

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 Hewitts Schauspielern, die durch das ursprüngliche Smalltalk ausgelöst wurden, waren eher im Geiste von OOP als die nachfolgenden Smalltalks. Wesentliche Teile von Erlang sind eher eine echte OOP Sprache, die das aktuelle Smalltalk ist, und sicherlich die C-basierten Sprachen, die mit "OOP Paint" gemalt wurden. "

Entnommen aus Alan Kays Kommentar unter:

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

6
Thiago Silva

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 in Bezug auf menschliche/menschliche mentale Modelle zu modellieren, anstatt zu sein nur ein Werkzeug für PROGRAMMIERER.

So wie ich es verstehe, war Alans Vision von OOP), den Computer zu einem Werkzeug zu machen, mit dem ein menschlicher Benutzer machen kann, was er will: Die vollen Fähigkeiten des Computers werden dem Endbenutzer direkt durch ein intuitives interaktives Modell. 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 ähnlich wie eine Person, die sein Verhalten beschreibt. 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 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 ROLLEN, keine TYPEN, und Sie möchten in der Lage sein, Methoden für "jedes Objekt zu definieren, das gerade diese Rolle spielt" ", weil dieses Verhalten Teil einer Systeminteraktion zwischen vielen sich ändernden Objekten ist und nicht Teil der Definition eines TYPES.

6
user1270393