Cosa intendeva Alan Kay per "incarico" in The Early History of Smalltalk?

Ho letto The Early History of Smalltalk e ci sono alcune menzioni di "incarico" che mi fanno mettere in dubbio la mia comprensione del suo significato:

Sebbene OOP provenisse da molte motivazioni, due erano centrali. Quello su larga scala era quello di trovare uno schema di modulo migliore per sistemi complessi che comportassero il nascondimento di dettagli, e quello su piccola scala era trovare una versione più flessibile di assegnazione e quindi tentare di eliminarlo del tutto.

(dal 1960-66 - Early OOP e altre idee formative degli anni sessanta , Sezione I)

Quello che ho ottenuto da Simula è che ora puoi sostituire attacchi e assegnazioni con obiettivi . L'ultima cosa che volevi che un programmatore facesse è confondere con lo stato interno anche se presentato in modo figurato. Invece, gli oggetti dovrebbero essere presentati come siti di comportamenti di livello superiore più appropriati per l'uso come componenti dinamici . (...) È un peccato che gran parte di ciò che oggi si chiama "programmazione orientata agli oggetti" sia semplicemente una programmazione vecchio stile con costrutti più elaborati. Molti programmi sono caricati con operazioni di tipo "assegnazione" ora eseguite con procedure annesse più costose.

(dallo stile "orientato agli oggetti" , sezione IV)

Ho ragione a interpretare l'intenzione come se gli oggetti fossero destinati a essere facciate e qualsiasi metodo (o "messaggio") il cui scopo è quello di impostare una variabile di istanza su un oggetto (cioè un "incarico") sta sconfiggendo lo scopo? Questa interpretazione sembra essere supportata da due successive dichiarazioni nella Sezione IV:

Quattro tecniche usate insieme - stato persistente, polimorfismo, istanziazione e metodi come obiettivi per l'oggetto - spiegano gran parte del potere. Nessuno di questi richiede un "linguaggio orientato agli oggetti" da utilizzare - ALGOL 68 può quasi essere trasformato in questo stile - e OOPL si concentra semplicemente sulla mente del progettista in una direzione particolarmente fruttuosa. Tuttavia, fare correttamente l'incapsulamento è un impegno non solo per l'astrazione dello stato, ma per eliminare dalla programmazione metafore orientate allo stato.

...e:

Le dichiarazioni di assegnazione, anche astratte, esprimono obiettivi di livello molto basso, e per realizzarli sarà necessario un numero maggiore di obiettivi. In generale, non vogliamo che il programmatore stia scherzando con lo stato, simulato o meno.

Sarebbe giusto dire che esempi opachi e immutabili vengono incoraggiati qui? O sono semplicemente i cambiamenti diretti dello stato a essere scoraggiati? Per esempio, se ho una BankAccountclasse, è ok per avere GetBalance, Deposite Withdrawmetodi di istanza / messaggi; assicurati solo che non ci sia un SetBalancemetodo / messaggio di istanza?

L'idea di base (influenzata da Sketchpad) è che la maggior parte delle variabili / valori sono in relazione dinamica tra loro (mantenute dall'interno dell'oggetto), quindi essere in grado di resettare direttamente un valore dall'esterno è pericoloso. Poiché (in Smalltalk comunque) è richiesto almeno un metodo setter, ciò consente alla possibilità di un'azione di impostazione esterna di essere mediata dal metodo interno per mantenere le interrelazioni desiderate. Ma la maggior parte delle persone che usano setter li usano semplicemente per simulare assegnazioni dirette a variabili interne, e questo viola lo spirito e l'intento del vero OOP.

Ma gli oggetti hanno "linee mondiali" di cambiamenti nel tempo. Questo può essere pensato come una "storia" delle versioni dell'oggetto in cui le relazioni sono in accordo. Non ci sono condizioni di gara in questo schema ... un oggetto è visibile solo quando è stabile e non è più calcolabile. Questo è come un orologio a due fasi in HW. (Idea da Strachey, e in modo diverso da McCarthy, e influenzato da Lucid.)

Auguri,

Alan Kay

Mi rendo conto che Alan abbia già risposto a questa domanda, e quindi potrebbe sembrare inutile rispondere ulteriormente. Tuttavia, Alan non ha risposto a tutte le tue domande.

In particolare:

Sarebbe giusto dire che esempi opachi e immutabili vengono incoraggiati qui? O sono semplicemente i cambiamenti diretti dello stato a essere scoraggiati? Ad esempio, se ho una classe BankAccount, è OK avere metodi / messaggi di istanza GetBalance, Deposit e Prelievo; assicurati solo che non ci sia un metodo / messaggio di istanza SetBalance?

La risposta qui è che non stai usando comportamenti di ordine superiore per strutturare il tuo programma. I sistemi di servizi finanziari del mondo reale non dovrebbero avere un metodo di deposito su una classe BankAccount, perché non è affatto così che funzionavano le banche prima dell'invenzione dei computer! Quando sono stati inventati i bancomat, hanno dovuto automatizzare letteralmente ciò che un cassiere ha fatto in banca. Il ruolo di un cassiere sarebbe quello di informare i clienti sullo stato del loro account. Per fare ciò, il cliente è autorizzato a interagire con il cassiere in pochi modi, come passare un buono di versamento al cassiere.

Reificando direttamente questi oggetti - Teller, Deposit Slip, ecc. - il dominio problematico è strutturato in base ai messaggi passati dalle entità nel sistema.

Un Conto stesso svolge un ruolo: l'idea di un Conto significa letteralmente un conto di afflussi e deflussi finanziari in relazione a un'attività, responsabilità, reddito o spesa. Un sistema di contabilità, o contabile, registra, conserva e riproduce questi flussi e ti dice la posizione finanziaria del conto in un determinato momento. Il rapporto più recente del Cassiere può essere considerato "in questo momento", ma non proprio: è proprio la posizione finanziaria descritta dal Ragioniere in un determinato momento. Ha l'illusione di essere "in questo momento" quando vai in banca, perché in genere sei l'unico autorizzato a effettuare pagamenti. Ciò era particolarmente vero 100 anni fa, ma oggi molte persone hanno pagamenti automatizzati,

Perché questo è importante? Bene, chiediti cosa devi fare per registrare una transazione:

Il cliente ha il proprio registro di controllo interno di tutto ciò che ha fatto, comprese le ricevute della banca. Allo stesso modo, la Banca mantiene il proprio registro di controllo interno di tutto ciò che ha fatto. La Banca sempre fa contabilità in partita doppia , nel senso che le transazioni record nel foglio Contabilità generale e l'equilibrio. Ciò consente alla Banca di eseguire la riconciliazionee assicurarsi che non vi siano voci spurie quando chiudono i libri per un determinato periodo finanziario (giornaliero, settimanale, mensile, trimestrale, annuale, bimestrale, qualunque cosa). Ciò suggerisce anche che il record per ciò che viene registrato dovrebbe essere idempotente. In altre parole, se dovessimo scrivere un programma per elencare tutte le transazioni univoche, potremmo farlo anche se nel nostro registro di controllo interno fossero presenti duplicati spuri, perché abbiamo incorporato identificativi di transazione idempotenti nei messaggi di registrazione.

Data la possibilità per i pagamenti automatici di addebitare e accreditare il tuo account, sembra logico che anche il contabile possa fare previsioni per te. Questa è stata la realizzazione dell'impatto che i computer potrebbero avere sui sistemi contabili. Di conseguenza, qualcuno ha inventato un sistema di contabilità chiamato Risorse-Eventi-Agenti che era più in linea con non solo guardare al passato, ma anche guardare al futuro e stimare i flussi di cassa con una granularità più fine di prima. In sostanza, REA è solo più metadati rispetto ai sistemi di contabilità classici, consentendo una migliore reportistica e analisi di business. Ad esempio, l'analisi della "catena del valore" e l'analisi della "catena di approvvigionamento" non sono cose facili da fare con la contabilità classica.

Allo stesso modo, Agoric Computing o Smart Contracts porta idee dai meccanismi di mercato all'informatica . È importante che quando fornisci una polizza di versamento fornisci anche un assegno o una borsa per depositare. Dal momento che c'è un tempo di attesa tra la ricezione dell'Assegno e il suo effettivo accesso al proprio Conto, è necessario un modo sicuro per gestire la valuta. A quanto pare, le funzionalità degli oggetti sono un modo naturale per ottenere valuta sicura distribuita. Possono essere usati per assicurarsi che Alice non tradisca Bob ritirando tutti i suoi fondi dopo aver scritto a Bob quell'assegno.