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 18:27 +0200 del 17/07/03, Stefan Ram ha scritto:
Caro dottor Kay,
Vorrei avere qualche 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 sapere di "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 'di tempo 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 avrebbe eliminato i dati e che "<-" sarebbe stato solo un altro token di messaggio (mi ci è voluto un po 'di tempo per pensarlo perché ho davvero pensato a tutti questi simboli come nomi per funzioni e procedure.
Il mio background in matematica 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 che ho adattato dalla "Generalizzazione dell'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 alcuna introduzione simile a un 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 guardare il file system USAF Burroughs 220 (che ho descritto nella storia di Smalltalk), il primo lavoro di Doug Ross al MIT (DAE e precedenti) in cui sosteneva l'incorporamento di puntatori di procedure in strutture di dati, Sketchpad (che aveva polimorfismo completo - dove ad esempio lo stesso offset nella sua struttura di dati significava "visualizzazione" e ci sarebbe un puntatore alla routine appropriata per il tipo di oggetto rappresentato dalla struttura, ecc., e 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 i dati e trovavano un puntatore a procedura. E i primi problemi che ho risolto con le mie prime cose nello Utah sono state 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 ingegnoso "Gedanken" (nel 1970 penso) in cui mostrò che usare la lamda le espressioni nel modo giusto consentirebbero di estrarre i dati mediante procedure. ma spesso potrebbe fare la cosa giusta se cercasse di cercare i dati e trovasse un puntatore alla procedura. E i primi problemi che ho risolto con le mie prime cose nello Utah sono state 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 ingegnoso "Gedanken" (nel 1970 penso) in cui mostrò che usare la lamda le espressioni nel modo giusto consentirebbero di estrarre i dati mediante procedure. ma spesso potrebbe fare la cosa giusta se cercasse di cercare i dati e trovasse un puntatore alla procedura. E i primi problemi che ho risolto con le mie prime cose nello Utah sono state 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 ingegnoso "Gedanken" (nel 1970 penso) in cui mostrò che usare la lamda le espressioni nel modo giusto consentirebbero di estrarre i dati mediante procedure.
Le persone a cui piacevano gli oggetti come non dati erano in numero inferiore e includevano me, Carl Hewitt, Dave Reed e pochi altri - praticamente tutto questo gruppo proveniva dalla comunità ARPA ed era coinvolto in un modo o nell'altro con il progettazione di ARPAnet → Internet in cui l'unità base di calcolo era un intero computer. Ma solo per mostrare quanto ostinatamente possa resistere un'idea, per tutti gli anni Settanta e Ottanta, c'erano molte persone che hanno cercato di cavarsela con "Remote Procedure Call" invece di pensare a oggetti e messaggi. Sic transit gloria mundi.
Saluti,
Alan Kay