it-swarm.it

Cosa significava * Alan Kay con il termine "orientato agli oggetti"?

Secondo quanto riferito, Alan Kay è l'inventore del termine "orientato agli oggetti". Ed è spesso citato per aver detto che ciò che chiamiamo OO oggi non è ciò che intendeva dire.

Ad esempio, l'ho appena trovato su Google:

Ho inventato il termine "orientato agli oggetti" e posso dirti che non avevo in mente C++

- Alan Kay, OOPSLA '97

Ricordo vagamente di aver sentito qualcosa di piuttosto perspicace su ciò che intendeva ha fatto. Qualcosa sulla falsariga del "passaggio di messaggi".

Sai cosa intendeva dire? Puoi fornire maggiori dettagli su ciò che intendeva dire e su come differisce dall'OO comune di oggi? Si prega di condividere alcuni riferimenti se ne hai.

Grazie.

104
Charlie Flowers

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


Data: mer 23 lug 2003 09:33:31 -0800 A: Stefan Ram [rimosso per la privacy] Da: Alan Kay [rimosso per la privacy] Oggetto: Ri: Chiarimento di "orientato agli oggetti"

Ciao Stefan -

Scusate il ritardo ma ero in vacanza.

Alle 6:27 PM +0200 17/07/03, Stefan Ram ha scritto:

Caro dottor Kay,

Vorrei avere una parola autorevole sul termine "programmazione orientata agli oggetti" per la mia pagina tutorial sull'argomento. Le uniche due fonti che considero "autorevoli" sono l'International Standards Organization, che definisce "orientato agli oggetti" in "ISO/IEC 2382-15", e tu, perché, come si suol dire, hai coniato quel termine.

Sono abbastanza sicuro di averlo fatto.

Sfortunatamente, è difficile trovare una pagina Web o una fonte con la tua definizione o descrizione di quel termine. Esistono diversi rapporti su ciò che potresti aver detto al riguardo (come "eredità, polimorfismo e incapsulamento"), ma questi non sono fonti di prima mano. Sono anche consapevole del fatto che in seguito avrai posto maggiormente l'accento sul "messaggistica", ma mi piacerebbe comunque conoscere "orientato agli oggetti".

Per la cronaca, la mia pagina tutorial e ulteriori distribuzioni e pubblicazioni potresti spiegare:

Quando e dove è stato usato per primo il termine "orientato agli oggetti"?

Nello Utah qualche tempo dopo il 66 novembre, quando, influenzato da Sketchpad, Simula, dal design di ARPAnet, dal Burroughs B5000 e dal mio background in Biologia e Matematica, ho pensato a un'architettura per la programmazione. Probabilmente fu nel 1967 quando qualcuno mi chiese cosa stavo facendo e io dissi: "È una programmazione orientata agli oggetti".

La sua concezione originale aveva le seguenti parti.

  • Ho pensato che gli oggetti fossero come cellule biologiche e/o singoli computer in una rete, in grado di comunicare solo con i messaggi (quindi la messaggistica è arrivata all'inizio - ci è voluto un po 'per vedere come fare la messaggistica in un linguaggio di programmazione in modo abbastanza efficiente da essere utile).

  • Volevo sbarazzarmi dei dati. Il B5000 ha quasi fatto questo tramite la sua architettura HW quasi incredibile. Mi sono reso conto che la metafora della cellula/intero computer si sarebbe sbarazzata dei dati e che "<-" sarebbe stato solo un altro token di messaggio (mi ci è voluto un po 'per pensarci perché ho davvero pensato a tutti questi simboli come nomi per funzioni e procedure.

  • Il mio background matematico mi ha fatto capire che ogni oggetto poteva avere diverse algebre associate ad esso, e che potevano esserci famiglie di questi, e che questi sarebbero stati molto utili. Il termine "polimorfismo" è stato imposto molto più tardi (penso da Peter Wegner) e non è del tutto valido, dal momento che proviene davvero dalla nomenclatura delle funzioni, e volevo molto più delle funzioni. Ho inventato un termine "generalità" per trattare comportamenti generici in una forma quasi algebrica.

  • Non mi piaceva il modo in cui Simula I o Simula 67 avevano ereditato (anche se pensavo che Nygaard e Dahl fossero solo grandi pensatori e designer). Così ho deciso di escludere l'eredità come funzionalità integrata fino a quando non ho capito meglio.

I miei esperimenti originali con questa architettura sono stati condotti usando un modello adattato dalla "Generalizzazione di ALGOL" di van Wijngaarten e Wirth e da Euler di Wirth. Entrambi erano piuttosto simili a LISP ma con una sintassi leggibile più convenzionale. Allora non ho capito l'idea mostruosa del metalinguaggio tangibile LISP, ma mi sono avvicinato un po 'alle idee su linguaggi estensibili tratti da varie fonti, incluso l'Imp di Irons.

La seconda fase di questo era comprendere finalmente LISP e quindi usare questa comprensione per rendere le sottostrutture molto più belle, più piccole e più potenti e più in ritardo. La tesi di Dave Fisher fu fatta in stile "McCarthy" e le sue idee sulle strutture di controllo estensibili furono molto utili. Un'altra grande influenza in quel momento fu il PIANIFICATORE di Carl Hewitt (che non ha mai ottenuto il riconoscimento che merita, dato quanto bene e quanto prima è stato in grado di anticipare Prolog).

Lo Smalltalk originale di Xerox PARC è uscito da quanto sopra. I successivi Smalltalk si lamentano della fine del capitolo Storia: hanno fatto marcia indietro verso Simula e non hanno sostituito i meccanismi di estensione con meccanismi più sicuri che erano quasi altrettanto utili.

Cosa significa "programmazione orientata agli oggetti" per te? (Non è necessaria un'introduzione di tipo tutorial, solo una breve spiegazione [come "programmazione con ereditarietà, polimorfismo e incapsulamento"] in termini di altri concetti per un lettore che abbia familiarità con loro, se possibile. Inoltre, non è necessario spiegare "oggetto" ", perché ho già delle fonti con la tua spiegazione di" oggetto "da" Early History of Smalltalk ".)

(Non sono contrario ai tipi, ma non conosco alcun tipo di sistema che non sia un problema completo, quindi mi piace ancora la digitazione dinamica.)

OOP per me significa solo messaggistica, conservazione locale, protezione e occultamento del processo statale ed estremo vincolo tardivo di tutte le cose. Può essere fatto in Smalltalk e in LISP. Probabilmente ci sono altri sistemi in cui ciò è possibile, ma non ne sono consapevole.

[Inoltre,] Una delle cose che avrei dovuto menzionare è che c'erano due percorsi principali che sono stati catalizzati da Simula. Il primo (solo per caso) è stato il percorso bio/net non-data-procedure che ho seguito. L'altro, che è arrivato poco dopo come oggetto di studio, era di tipi di dati astratti, e questo ha avuto molto più gioco.

Se osserviamo tutta la storia, vediamo che la roba proto-OOP è iniziata con ADT, ha avuto un piccolo fork verso quello che ho chiamato "oggetti" - che ha portato a Smalltalk, ecc. - ma dopo il piccolo fork, il L'istituzione di CS praticamente ha fatto l'ADT e voleva attenersi al paradigma della procedura dei dati. Storicamente, vale la pena esaminare il file system USAF Burroughs 220 (che ho descritto nella storia di Smalltalk), il primo lavoro di Doug Ross a MIT (AED e precedenti) in cui ha sostenuto la procedura di incorporamento puntatori nelle strutture dati, Sketchpad (che aveva un polimorfismo completo - dove ad esempio lo stesso offset nella sua struttura dati significava "display" e ci sarebbe un puntatore alla routine appropriata per il tipo di oggetto rappresentato dalla struttura, ecc., e il Burroughs B5000, le cui tabelle di riferimento del programma erano veri e propri "grandi oggetti" e contenevano puntatori a "dati" e "procedure" ma spesso potevano fare la cosa giusta se cercavano di cercare dati e trovavano un puntatore a procedura. i problemi che ho risolto con le mie prime cose nello Utah erano la "scomparsa dei dati" usando solo metodi e oggetti. Alla fine degli anni '60 (penso) Bob Balzer scrisse un documento piuttosto ingegnoso chiamato "Programmazione Dataless", e poco dopo John Reynolds scrisse un documento altrettanto elegante "Ged anken "(nel 1970 credo) in cui ha dimostrato che l'uso delle espressioni lamda nel modo giusto consentirebbe di estrarre i dati mediante procedure.

Le persone a cui piacevano gli oggetti come non-dati erano in numero minore e includevano me, Carl Hewitt, Dave Reed e pochi altri - praticamente tutto questo gruppo proveniva dalla comunità ARPA e sono stati coinvolti in un modo o nell'altro nella progettazione di ARPAnet → Internet in cui l'unità di calcolo di base era un intero computer. Ma solo per dimostrare quanto ostinatamente un'idea possa rimanere aggrappata, per tutti gli anni Settanta e Ottanta, c'erano molte persone che ho provato a cavarmela con "Remote Procedure Call" invece di pensare a oggetti e messaggi. Sic transit gloria mundi.

Saluti,

Alan Kay

90
Manoj

La maggior parte se non tutto ciò che Alan Kay intendeva per orientamento all'oggetto è incarnato nel linguaggio Smalltalk.

Inoltre, da http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay ha sostenuto che il passaggio dei messaggi è più importante degli oggetti in OOP e che gli oggetti stessi sono spesso enfatizzati. Il modello di programmazione di oggetti distribuiti dal vivo si basa su questa osservazione; utilizza il concetto di un flusso di dati distribuito per caratterizzare il comportamento di un sistema distribuito complesso in termini di modelli di messaggi, utilizzando specifiche di alto livello in stile funzionale.
23
Mark Cidade

La maggior parte se non tutto ciò che Alan Kay intendeva per orientamento dell'oggetto è incarnato nel linguaggio Smalltalk.

"Non abbiamo nemmeno fatto tutta l'idea al PARC. Molte delle idee di attori di Carl Hewitt che sono state scatenate dall'originale Smalltalk erano più nello spirito di OOP delle successive Smalltalks. Parti significative di Erlang sono più simili a un vero OOP linguaggio l'attuale Smalltalk, e certamente i linguaggi basati su C che sono stati dipinti con "OOP Paint". "

Tratto dal commento di Alan Kay a:

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

6
Thiago Silva

Uno dei punti principali che ho raccolto seguendo le opere di Alan Kay e altri come Jim Coplien è che la vera programmazione orientata agli "oggetti" riguarda la modellazione di computer e software in termini di modelli mentali UMANI/UTENTE, piuttosto che essere solo uno strumento per PROGRAMMATORI.

A quanto ho capito, la visione di Alan di OOP stava trasformando il computer in uno strumento che consente a un utente umano di realizzare tutto ciò che voleva: tutte le funzionalità del computer sono direttamente esposte all'utente finale attraverso un modello interattivo intuitivo. Dovrei essere in grado di visualizzare e scolpire gli oggetti e le interazioni di runtime DIRETTAMENTE, non solo tramite il codice.

Ecco un post sui miei piani per tentare una versione di questo in JavaScript come prova del concetto: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Dal punto di vista dello sviluppo/programmazione del software, Jim Coplien parla di come il codice può e DOVREBBE assomigliare al modello mentale degli utenti. Cioè, il codice legge più o meno allo stesso modo in cui suonerebbe una persona che descrive il suo comportamento. Ciò è in gran parte realizzato pensando in termini di OGGETTI, piuttosto che in termini di CLASSI e TIPI. Il comportamento è descritto in base ai RUOLI giocati dagli oggetti, non come parte della definizione dell'IDENTITÀ di un oggetto. Dovresti essere in grado di modellare le interazioni in termini di oggetti, che sono identificati dal RUOLO che giocano in un'interazione. Ecco come funzionano i modelli mentali umani: cameriere, cliente, cassiere, account di origine, account di destinazione, ... Questi sono RUOLI, non TIPI, e vuoi essere in grado di definire i metodi per "qualunque oggetto stia giocando questo ruolo in quel momento ", perché tale comportamento fa parte di un'interazione di sistema tra molti oggetti in evoluzione, piuttosto che parte della definizione di alcuni TIPI.

6
user1270393