アラン・ケイは、Smalltalkの初期の歴史における「割り当て」とはどういう意味ですか？

私はSmalltalkの初期の歴史を読んでおり、その意味の理解に疑問を抱かせる「割り当て」についての言及がいくつかあります。

OOPは多くの動機から来ましたが、2つが中心でした。大規模なものは詳細の隠蔽を伴う複雑なシステムのためのより良いモジュールスキームを見つけることであり、小規模なものは割り当てのより柔軟なバージョンを見つけることであり、それからそれを完全に排除しようとしました。

（1960-66から-初期のOOPおよび60年代のその他の形成的アイデア、セクションI）

Simulaから得たのは、バインディングと割り当てを目標に置き換えることができるということです。プログラマーに最後に望むことは、たとえ比fig的に提示されたとしても、内部状態を混乱させることです。代わりに、オブジェクトは、動的コンポーネントとしての使用により適した、より高いレベルの動作のサイトとして提示される必要があります。（...）残念なことに、今日「オブジェクト指向プログラミング」と呼ばれるものの多くが、より洗練された構成要素を備えた単純な古いスタイルのプログラミングである。多くのプログラムには、より高価な添付プロシージャによって実行される「割り当てスタイル」操作がロードされています。

（「オブジェクト指向」スタイル、セクションIVから）

オブジェクトがファサードであり、オブジェクトにインスタンス変数を設定することを目的とするメソッド（または「メッセージ」）（つまり「割り当て」）が目的に反しているという意図を解釈するのは正しいですか？この解釈は、セクションIVの後半の2つのステートメントでサポートされているようです。

永続状態、ポリモーフィズム、インスタンス化、およびオブジェクトの目標としてのメソッドの4つの手法が一緒に使用され、多くの権限を占めています。これらのいずれも「オブジェクト指向言語」を採用する必要はありません--ALGOL 68はほとんどこのスタイルに変えることができます-そして、OOPLは単に特定の実りある方向にデザイナーの心を集中させます。ただし、カプセル化を正しく行うことは、状態の抽象化だけでなく、プログラミングから状態指向のメタファーを排除することを約束するものです。

...そして：

割り当てステートメントは、抽象的なものであっても、非常に低いレベルの目標を表します。何かを成し遂げるためには、それらの多くが必要になります。一般に、シミュレートされているかどうかに関係なく、プログラマが状態をいじり回すことは望ましくありません。

ここでは、不透明で不変のインスタンスが推奨されていると言ってもいいでしょうか？または、推奨されていない単純な状態変更ですか？私が持っている場合たとえば、BankAccountクラスを、それが持ってOKだGetBalance、DepositとWithdrawインスタンスメソッド/メッセージ。SetBalanceインスタンスメソッド/メッセージがないことを確認してください？

基本的な考え方（Sketchpadの影響を受けます）は、ほとんどの変数/値が互いに動的（関係）にある（オブジェクトの内部によって維持される）ため、外部から値を直接リセットできることは危険です。（とにかくSmalltalkでは）少なくともsetterメソッドが必要なので、これにより外部の設定アクションが内部メソッドによって仲介され、望ましい相互関係が維持される可能性があります。しかし、セッターを使用するほとんどの人は、単に内部変数への直接割り当てをシミュレートするためにそれらを使用します。これは、実際のOOPの精神と意図に違反します。

しかし、オブジェクトには時間の変化の「世界線」があります。これは、-関係-が一致するオブジェクトのバージョンの-履歴-と考えることができます。このスキームには競合状態はありません...オブジェクトは、安定していて計算を行っていないときにのみ表示されます。これは、HWの2フェーズクロックのようなものです。（Stracheyからのアイデア、およびMcCarthyからのアイデアとは異なり、Lucidの影響を受けています。）

ご多幸を祈る、

アラン・ケイ

アランはすでにこの質問に答えていたので、さらに返信するのは無意味だと思うかもしれません。しかし、アランはあなたが持っているすべての質問に答えたわけではありません。

特に：

ここでは、不透明で不変のインスタンスが推奨されていると言ってもいいでしょうか？または、推奨されていない状態の変更を直接指示するだけですか？たとえば、BankAccountクラスがある場合、GetBalance、Deposit、Withdrawのインスタンスメソッド/メッセージを使用してもかまいません。SetBalanceインスタンスのメソッド/メッセージがないことを確認してください。

ここでの答えは、プログラムを構造化するために高次の動作を使用していないということです。実際の金融サービスシステムでは、BankAccountクラスにDepositメソッドを使用しないでください。これは、コンピューターが発明される前の銀行の仕組みとはまったく異なるためです。ATMが発明されたとき、テラーが銀行で行ったことを文字通り自動化する必要がありました。テラーの役割は、アカウントのステータスについて顧客に通知することです。これを行うために、顧客は預け入れ伝票をテラーに渡すなど、いくつかの方法でテラーとやり取りすることができます。

これらのオブジェクト（テラー、デポジットスリップなど）を直接具体化することにより、システム内のエンティティから渡されるメッセージに従って問題ドメインが構築されます。

アカウント自体が役割を果たします。アカウントの概念は、文字通り、資産、負債、収入、または費用に関連する金融の流入と流出のアカウントを意味します。会計システム、または会計士は、これらのフローを記録、保持、再現し、ある時点でのアカウントの財政状態を通知します。テラーによる最新のレポートは、「今」と考えることができますが、実際にはそうではありません。それは、ある時点で会計士によって説明された財政状態です。銀行に行くと「今」であるかのように錯覚します。一般に、支払いを行う権限を与えられているのはあなただけだからです。これは特に100年前に当てはまりましたが、今日では多くの人が自動支払いを行っており、

何でこれが大切ですか？さて、トランザクションを記録するために何をする必要があるかを自問してください：

お客様は、銀行からの領収書を含む、行ったすべての内部監査ログを所有しています。同様に、銀行は自分が行ったすべての内部監査ログを保持しています。銀行は常に行い、ダブルエントリー会計を総勘定元帳と貸借対照表では、それらのレコードのトランザクションを意味し、。これにより、銀行は調整を実行できますまた、特定の会計期間（毎日、毎週、毎月、四半期、毎年、半年ごとなど）に書籍を閉じるときに偽のエントリがないことを確認します。これは、記録されるものの記録がべき等であるべきであることも示唆しています。つまり、一意のトランザクションをすべてリストするプログラムを作成する場合、内部監査ログに偽の重複があったとしても、ログメッセージにべき等トランザクション識別子を埋め込んだため、そうすることができました。

アカウントの借方と貸方に自動支払いができることを考えると、会計士もあなたのために予測を行うことができるのは理にかなっているようです。これは、コンピューターが会計システムに与える影響の実現でした。したがって、誰かが、Resources-Events-Agentsと呼ばれる会計システムスキームを発明しました。これは、過去を見るだけでなく、将来を見て、以前よりも細かい粒度でキャッシュフローを推定するという、よりインラインです。基本的に、REAは従来の会計システムが持っていたよりも多くのメタデータであり、より良いレポートとビジネス分析を可能にします。たとえば、「バリューチェーン」分析と「サプライチェーン」分析は、従来の会計では簡単に行えません。

同様に、Agoric ComputingまたはSmart Contractsは、市場メカニズムからコンピューティングにアイデアをもたらします。入金伝票を提出する際には、入金する小切手または財布も提出することが重要です。小切手を受け取ってから実際にアカウントに入るまでにリードタイムがあるため、通貨を管理する安全な方法が必要です。結局のところ、オブジェクト機能は、分散した安全な通貨を実現するための自然な方法です。アリスがボブに小切手を書いた後、すべての資金を引き出してボブをだまさないようにするために使用できます。