O que Alan Kay quis dizer com “designação” em The Early History of Smalltalk?

45

Eu tenho lido O início da história do Smalltalk e há algumas menções de "atribuição" que fazem eu questiono minha compreensão do seu significado:

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.

(de 1960-66 - Early OOP e outras idéias formativas dos anos sessenta , Seção 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.

(de "Estilo orientado a objetos" , Seção IV)

Estou correto em interpretar a intenção como sendo que os objetos são feitos para ser fachadas e qualquer método (ou "mensagem") cuja finalidade é definir uma variável de instância em um objeto (ou seja, uma "atribuição") está derrotando a finalidade ? Esta interpretação parece ser apoiada por duas declarações posteriores na Seção 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.

Seria justo dizer que exemplos opacos e imutáveis estão sendo encorajados aqui? Ou é simplesmente direto mudanças de estado que são desencorajadas? Por exemplo, se eu tiver uma classe BankAccount , não há problema em ter GetBalance , Deposit e Withdraw instance métodos / mensagens; apenas certifique-se de que não haja um método / mensagem SetBalance instance?

    
por Olivier Dagenais 03.06.2011 / 04:52
fonte

2 respostas

82

A ideia básica (influenciada pelo Sketchpad) é que a maioria das variáveis / valores estão em relações de dinâmica entre si (mantidas pelo interior do objeto), portanto, ser capaz de redefinir diretamente um valor a partir do exterior é perigoso. Como (no Smalltalk, de qualquer maneira) existe pelo menos um método setter requerido, isto permite a possibilidade de uma ação de configuração externa ser mediada pelo método interno para manter as inter-relações desejadas. Mas a maioria das pessoas que usam setters simplesmente as usam para simular atribuições diretas a variáveis internas, e isso viola o espírito e a intenção da OOP real.

Mas os objetos têm "linhas do mundo" de mudanças no tempo. Isso pode ser pensado como uma história das versões do objeto em que as relações estão de acordo. Não há condições de corrida neste esquema ... um objeto só é visível quando está estável e não está mais computando. Isto é como um relógio de duas fases em HW. (Idéia de Strachey, e diferente de McCarthy, e influenciada por Lucid.)

Felicidades,

Alan Kay

    
por 03.06.2011 / 12:47
fonte
21

Eu percebo que Alan já respondeu a essa pergunta, e assim pode parecer que é inútil responder mais. No entanto, Alan não respondeu a todas as perguntas que você tinha.

Em particular:

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?

A resposta aqui é que você não está usando um comportamento de ordem superior para estruturar seu programa. Os sistemas de serviços financeiros do mundo real não devem ter um método de depósito em uma classe BankAccount, porque não é assim que os bancos funcionavam antes da invenção dos computadores! Quando os caixas eletrônicos foram inventados, eles tiveram que automatizar literalmente o que um Caixa fez no banco. O papel de um Caixa seria notificar os clientes sobre o status de sua conta. Para fazer isso, o cliente pode interagir com o Caixa de poucas maneiras, como passar um comprovante de depósito para o Caixa.

Ao reificar diretamente esses objetos - Caixa, Depósito, etc. - o domínio do problema é estruturado de acordo com as mensagens transmitidas pelas entidades no sistema.

Uma Conta em si desempenha um papel - a ideia de uma Conta significa literalmente uma conta de entradas e saídas financeiras em relação a um Ativo, Responsabilidade, Renda ou Despesa. Um sistema de contabilidade, ou contador, registra, retém e reproduz esses fluxos e informa a posição financeira da conta em um determinado momento. O relatório mais recente do Teller pode ser pensado como "agora mesmo", mas não realmente: é realmente a posição financeira descrita pelo Contador em um determinado momento. Apenas tem a ilusão de ser "agora mesmo" quando você vai ao banco, porque geralmente você é o único autorizado a fazer pagamentos. Isso foi especialmente verdadeiro há 100 anos, mas hoje muitas pessoas têm pagamentos automatizados, e a conta pode mudar enquanto você está fisicamente no banco segurando um boleto - porque o boleto só informa sobre o horário em que foi registrado. .

Por que isso é importante? Bem, pergunte a si mesmo o que precisa ser feito para registrar uma transação:

O Cliente tem seu próprio log de auditoria interna de tudo o que fez, incluindo recibos do Banco. Da mesma forma, o Banco mantém seu próprio registro de auditoria interna de tudo o que fez. O Banco sempre faz contabilidade de dupla entrada , o que significa que registra transações no Razão Geral e Balanço Patrimonial. Isso permite que o Banco realize a reconciliação e certifique-se de que não haja entradas falsas quando fecham seus livros por um determinado período financeiro (diário, semanal, mensal, trimestral, anual, semestral, seja qual for) . Isso também sugere que o registro do que é gravado deve ser idempotente. Ou seja, se fôssemos escrever um programa para listar todas as transações exclusivas, poderíamos fazê-lo mesmo se duplicatas espúrias estivessem em nosso log de auditoria interna, porque incorporamos identificadores de transação idempotente nas mensagens de log.

Dada a capacidade de pagamentos automáticos para debitar e creditar sua conta, parece fazer sentido que o Contador também possa fazer previsão para você. Essa foi a percepção do impacto que os computadores poderiam ter nos sistemas contábeis. Assim, alguém inventou um esquema de sistema de contabilidade chamado Resources-Events-Agents que estava mais alinhado com não apenas olhar no passado, mas também olhando para o futuro e estimando fluxos de caixa em uma granularidade mais fina do que antes. Essencialmente, a REA é apenas mais metadados do que os sistemas contábeis clássicos, permitindo um melhor relatório e análise de negócios. Por exemplo, a análise da "cadeia de valor" e a análise da "cadeia de suprimentos" não são coisas fáceis de se fazer com a contabilidade clássica.

Da mesma forma, Agoric Computing ou Smart Contracts traz ideias dos mecanismos de mercado para a computação. É importante que, ao fornecer um comprovante de depósito, você também forneça um cheque ou uma ordem para depositar. Como há um tempo de espera entre o recebimento do cheque e a entrada na sua conta, você precisa de uma maneira segura de gerenciar a moeda. Como se constata, os recursos de objeto são uma maneira natural de obter moeda segura distribuída. Eles podem ser usados para garantir que Alice não engane Bob retirando todos os seus fundos depois que ela escreveu a Bob o cheque.

    
por 10.06.2011 / 01:42
fonte