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.