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

Eu tenho lido The Early History of Smalltalk e há algumas menções de "designação" que me fazem questionar minha compreensão de seu significado:

Embora a OOP tenha provocado muitas motivações, duas eram centrais. O de grande escala consistia em encontrar um esquema de módulo melhor para sistemas complexos que envolvem ocultação de detalhes, e o de pequena escala consistia em encontrar uma versão mais flexível da atribuição e depois tentar eliminá-la completamente.

(de 1960 a 66 - OOP inicial e outras idéias formativas dos anos sessenta , Seção I)

O que eu recebi de Simula foi que agora você poderia substituir os vínculos e as tarefas por objetivos . A última coisa que você queria que qualquer programador fizesse era mexer com o estado interno, mesmo que apresentado de maneira figurada. Em vez disso, os objetos devem ser apresentados como site de comportamentos de nível superior, mais apropriados para uso como componentes dinâmicos . (...) É lamentável que muito do que hoje é chamado de "programação orientada a objetos" seja simplesmente programação de estilo antigo com construções mais sofisticadas. Muitos programas são carregados com operações de "estilo de atribuição", agora executadas por procedimentos anexos mais caros.

(do estilo "Orientado a objetos" , Seção IV)

Estou correto ao interpretar a intenção de que os objetos devem ser fachadas e qualquer método (ou "mensagem") cujo objetivo é definir uma variável de instância em um objeto (isto é, uma "atribuição") está vencendo a finalidade? Essa interpretação parece ser apoiada por duas declarações posteriores na Seção IV:

Quatro técnicas usadas em conjunto - estado persistente, polimorfismo, instanciação e métodos como objetivos para o objeto - são responsáveis ​​por grande parte do poder. Nada disso exige que uma "linguagem orientada a objetos" seja empregada - o ALGOL 68 quase pode ser voltado para esse estilo - e a OOPL apenas concentra a mente do designer em uma direção frutífera específica. No entanto, fazer o encapsulamento correto é um compromisso não apenas com a abstração do estado, mas com a eliminação de metáforas orientadas pelo estado da programação.

...e:

As declarações de atribuição - mesmo as abstratas - expressam objetivos de nível muito baixo, e serão necessários mais deles para que tudo seja feito. Geralmente, não queremos que o programador esteja mexendo com o estado, simulado ou não.

Seria justo dizer que instâncias opacas e imutáveis ​​estão sendo encorajadas aqui? Ou simplesmente as mudanças diretas de estado são desencorajadas? Por exemplo, se eu tiver uma BankAccountclasse, não há problema em ter GetBalance, Deposite Withdrawmétodos de instância / mensagens; apenas verifique se não há um SetBalancemétodo / mensagem de instância?

A idéia básica (influenciada pelo Sketchpad) é que a maioria das variáveis ​​/ valores está em relações dinâmicas entre si (mantidas pelo interior do objeto), portanto, é possível redefinir diretamente um valor do lado de fora. Como (no Smalltalk de qualquer maneira) há pelo menos um método setter necessário, isso 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 usa setters simplesmente as usa para simular atribuições diretas a variáveis ​​interiores, e isso viola o espírito e a intenção do verdadeiro POO.

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

Muitas felicidades,

Alan Kay

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

Em particular:

Seria justo dizer que instâncias opacas e imutáveis ​​estão sendo encorajadas aqui? Ou simplesmente as mudanças diretas de estado são desencorajadas? Por exemplo, se eu tiver uma classe BankAccount, não há problema em obter métodos / mensagens de instância GetBalance, Deposit e Withdraw; apenas verifique se não há um método / mensagem de instância SetBalance?

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 literalmente automatizar o que um caixa fazia 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 apenas algumas maneiras, como passar um comprovante de depósito para o Caixa.

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

A própria conta desempenha um papel - a ideia de uma conta significa literalmente uma conta de entradas e saídas financeiras em relação a um ativo, passivo, receita 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 Caixa pode ser considerado "agora", mas não realmente: é realmente a posição financeira descrita pelo Contador em determinado momento. Apenas tem a ilusão de estar "agora" quando você vai ao banco, porque geralmente você é o único autorizado a efetuar pagamentos. Isso foi especialmente verdadeiro há 100 anos, mas hoje muitas pessoas têm pagamentos automatizados,

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

O Cliente possui seu próprio registro de auditoria interna de tudo o que fez, incluindo recebimentos 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 , ou seja, registra transações no Razão e no Balanço. Isso permite que o Banco realize reconciliaçãoe verifique se não há entradas falsas ao fechar seus livros por um determinado período financeiro (diariamente, semanalmente, mensalmente, trimestralmente, anualmente, semestralmente, o que for). Isso também sugere que o registro do que é gravado deve ser idempotente. Ou seja, se escrevêssemos 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 idempotentes nas mensagens de log.

Dada a capacidade de pagamentos automatizados debitar e creditar sua conta, parece fazer sentido que o contador também possa fazer previsões para você. Essa foi a percepção do impacto que os computadores poderiam ter nos sistemas de contabilidade. Dessa forma, alguém inventou um esquema de sistema de contabilidade chamado Resources-Events-Agents que era mais alinhado não apenas com o passado, mas também com o futuro e com a estimativa dos fluxos de caixa com uma granularidade mais fina do que antes. Essencialmente, o REA é apenas mais metadados do que os sistemas contábeis clássicos tinham, permitindo melhores relatórios e análises de negócios. Por exemplo, análise de "cadeia de valor" e análise de "cadeia de suprimentos" não são fáceis de fazer com a contabilidade clássica.

Da mesma forma, a computação Agoric ou os contratos inteligentes traz idéias 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 bolsa para depositar. Como existe um prazo de entrega entre o recebimento do cheque e o fato de ele entrar na sua conta, você precisa de uma maneira segura de gerenciar a moeda. Como se vê, os recursos do 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 esse cheque a Bob.