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

45

Ho letto The Early History of Smalltalk e ci sono alcune menzioni di "assegnazione" che rendono mi interrogo sulla mia comprensione del suo significato:

Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.

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

What I got from Simula was that you could now replace bindings and assignment with goals. The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. Instead, the objects should be presented as site of higher level behaviors more appropriate for use as dynamic components. (...) It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs. Many programs are loaded with "assignment-style" operations now done by more expensive attached procedures.

(da "Stile orientato agli oggetti" , Sezione IV)

Sono corretto nell'interpretare l'intento che gli oggetti sono pensati per essere facciate e qualsiasi metodo (o "messaggio") il cui scopo è quello di impostare una variabile di istanza su un oggetto (cioè un "assegnamento") sta vanificando lo scopo ? Questa interpretazione sembra essere supportata da due dichiarazioni successive nella Sezione IV:

Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power. None of these require an "object-oriented language" to be employed--ALGOL 68 can almost be turned to this style--and OOPL merely focuses the designer's mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.

... e:

Assignment statements--even abstract ones--express very low-level goals, and more of them will be needed to get anything done. Generally, we don't want the programmer to be messing around with state, whether simulated or not.

Sarebbe corretto dire che qui vengono incoraggiate istanze opache e immutabili? O sono semplicemente direct cambiamenti di stato che sono scoraggiati? Ad esempio, se ho una classe BankAccount , è OK avere GetBalance , Deposit e Withdraw metodi / messaggi di istanza; assicurati che non ci sia un metodo / messaggio di istanza SetBalance ?

    
posta Olivier Dagenais 03.06.2011 - 04:52
fonte

2 risposte

82

L'idea di base (influenzata da Sketchpad) è che la maggior parte delle variabili / valori sono in dinamiche relazioni con l'altro (mantenute dall'interno dell'oggetto), quindi essere in grado di ripristinare direttamente un valore dall'esterno è pericoloso. Perché (in Smalltalk comunque) c'è almeno un metodo di settaggio richiesto, questo consente la possibilità di un'azione di impostazione esterna essere mediata dal metodo interno per mantenere le interrelazioni desiderate. Ma la maggior parte delle persone che usano i setter li usa semplicemente per simulare assegnazioni dirette alle variabili interiori, e questo viola lo spirito e l'intento del vero OOP.

Ma gli oggetti hanno "linee del mondo" di cambiamenti nel tempo. Questo può essere pensato come una storia di 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 sta più calcolando. Questo è come un orologio a due fasi in HW. (Idea di Strachey, e in una versione diversa da McCarthy, e influenzata da Lucid.)

Un caro saluto,

Alan Kay

    
risposta data 03.06.2011 - 12:47
fonte
21

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

In particolare:

Would it be fair to say that opaque, immutable instances are being encouraged here? Or is it simply direct state changes that are discouraged? For example, if I have a BankAccount class, it's OK to have GetBalance, Deposit and Withdraw instance methods/messages; just make sure there isn't a SetBalance instance method/message?

La risposta è che non si sta utilizzando un comportamento di ordine superiore per strutturare il programma. I sistemi di servizi finanziari del mondo reale non dovrebbero avere un metodo di deposito su una classe BankAccount, perché non è affatto come le banche lavoravano prima dell'invenzione dei computer! Quando i bancomat sono stati inventati, hanno dovuto letteralmente automatizzare ciò che un Teller ha fatto in banca. Il ruolo di un Teller sarebbe quello di informare i clienti sullo stato del loro account. Per fare questo, al cliente è consentito interagire con il Teller in pochi modi, come passare un Slip di deposito al Teller.

Attraverso la reificazione diretta di questi oggetti - Teller, Deposit Slip, ecc. - il dominio del problema è strutturato in base ai messaggi trasmessi dalle entità nel sistema.

Un Account in sé svolge un ruolo - l'idea di un Conto significa letteralmente un conto di flussi finanziari in entrata e in uscita in relazione a un Asset, Liability, Income o Expense. Un sistema contabile o contabile, registra, conserva e riproduce questi flussi e indica la posizione finanziaria dell'account in un determinato momento. Il rapporto più recente del Teller può essere pensato come "in questo momento", ma non proprio: è davvero la posizione finanziaria descritta dal Contabile in un determinato momento. Ha solo l'illusione di essere "in questo momento" quando vai in banca, perché generalmente sei l'unico autorizzato ad effettuare pagamenti. Questo era particolarmente vero 100 anni fa, ma oggi molte persone hanno automatizzato i pagamenti e l'account può cambiare mentre si è fisicamente in banca con un Balance Slip - perché il Balance Slip ti dice solo del momento in cui è stato timestamp .

Perché è così importante? Bene, chiediti cosa deve essere fatto per registrare una transazione:

Il Cliente ha il proprio registro di controllo interno di tutto ciò che ha fatto, incluse le ricevute dalla Banca. Allo stesso modo, la Banca conserva il proprio registro di controllo interno di tutto ciò che ha fatto. La sempre della banca contabilità a partita doppia , nel senso che registrano le transazioni nella contabilità generale e stato patrimoniale. Ciò consente alla Banca di eseguire riconciliazione e assicurarsi che non vi siano voci spurie quando chiudono i libri per un dato periodo finanziario (giornaliero, settimanale, mensile, trimestrale, annuale, biennale, qualunque) . Ciò suggerisce anche che il record di ciò che viene registrato dovrebbe essere idempotente. Significa, se dovessimo scrivere un programma per elencare tutte le transazioni univoche, potremmo farlo anche se nel nostro registro di controllo interno fossero presenti doppi duplicati, perché abbiamo incorporato identificativi di transazione identi- ficativi nei messaggi di registrazione.

Data la possibilità per i pagamenti automatici di addebitare e accreditare sul tuo conto, sembra logico che l'Accountant possa anche fare previsioni per te. Questa è stata la realizzazione dell'impatto che i computer potrebbero avere sui sistemi di contabilità. Di conseguenza, qualcuno ha inventato uno schema di sistema contabile chiamato Risorse-Eventi-Agenti che era più in linea con non solo guardando in passato, ma anche guardando al futuro e stimando i flussi di cassa con una granularità più fine di prima. Essenzialmente, la REA è solo più metadata dei sistemi di contabilità classica, consentendo una migliore segnalazione e analisi di business. Ad esempio, l'analisi della "catena del valore" e l'analisi della "supply chain" non sono cose facili da fare con la contabilità classica.

Allo stesso modo, Agoric Computing o Smart Contracts portano idee dai meccanismi del mercato al computing. È importante che quando fornisci un Slip di deposito fornisci anche un assegno o un borsellino da depositare. Poiché c'è un tempo di attesa tra la ricezione del controllo e l'accesso al 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 utilizzati per garantire che Alice non imbrogli Bob ritirando tutti i suoi fondi dopo aver scritto a Bob quell'assegno.

    
risposta data 10.06.2011 - 01:42
fonte