Smalltalkの初期の歴史における「割り当て」によってアラン・ケイは何を意味しましたか？
私は Smalltalkの初期の歴史 を読んでいて、「割り当て」についていくつかの言及があり、その意味の理解に疑問を投げかけています。
OOPは多くの動機から来ましたが、2つが中心でした。大規模なものは詳細の非表示を含む複雑なシステムのより良いモジュールスキームを見つけることであり、小規模なものはより柔軟なものを見つけることでした割り当てのバージョン、そしてそれを完全に排除しようとすること。
（ 1960-66から-初期OOPおよび60年代の他の形成的アイデア、セクションI））
Simulaから得たのは、バインディングと割り当てを goals に置き換えることができるということです。プログラマーにしてほしい最後のことは、たとえ比喩的に提示されていても、内部状態を混乱させることです。代わりに、オブジェクトは動的コンポーネントとして使用するのにより適切な高レベルの動作のサイトとして提示する必要があります。 （...）今日「オブジェクト指向プログラミング」と呼ばれているものの多くが、より洗練された構造を持つ単に古いスタイルのプログラミングであることは残念です。多くのプログラムには、「割り当てスタイル」の操作が読み込まれ、より高価な添付プロシージャによって実行されるようになりました。
（「オブジェクト指向」スタイル、セクションIVから））
オブジェクトはファサードであり、オブジェクトにインスタンス変数を設定することを目的とするメソッド（または「メッセージ」）（つまり、「割り当て」）が目的を無効にすることを意図していると解釈すると、私は正しいですか？この解釈は、セクションIVの後の2つのステートメントによってサポートされているようです。
一緒に使用される4つの手法（永続状態、多態性、インスタンス化、およびオブジェクトの目的としてのメソッド）が、パワーの多くを占めています。これらはどれも「オブジェクト指向言語」を採用する必要がなく、ALGOL 68はほとんどこのスタイルに変えることができます。そしてOOPLは設計者の心を特定の実りある方向に集中させるだけです。しかし、 、カプセル化を正しく行うことは、状態を抽象化するだけでなく、プログラミングから状態指向のメタファを排除することへの取り組みです。
...そして：
割り当てステートメント（抽象的なものでも）は非常に低レベルの目標を表しており、何かを成し遂げるにはさらに多くの目標が必要になります。一般的に、シミュレートされているかどうかに関係なく、プログラマーが状態をいじり回すことは望ましくありません。
ここでは不透明で不変のインスタンスが奨励されていると言ってよいでしょうか？それとも、単に direct 状態の変更が推奨されないのですか？たとえば、BankAccountクラスがある場合、GetBalance、Deposit、Withdrawのインスタンスメソッド/メッセージがあっても問題ありません。 SetBalanceインスタンスメソッド/メッセージがないことを確認してください。
（スケッチパッドの影響を受けた）基本的な考え方は、ほとんどの変数/値は互いに（オブジェクトの内部によって維持される）動的な関係にあるため、外部から直接値をリセットすることは危険であるということです。 （とにかくSmalltalkでは）少なくともセッターメソッドが必要なため、これにより、外部設定アクションが内部メソッドによって仲介され、目的の相互関係を維持できるようになります。しかし、セッターを使用するほとんどの人は、それらを使用して内部変数への直接割り当てをシミュレートするだけであり、これは実際のOOPの精神と意図に違反します。
しかし、オブジェクトには時間の変化の「世界線」があります。これは、関係の一致したオブジェクトのバージョンの履歴として考えることができます。このスキームには競合状態はありません...オブジェクトは、それが安定していて計算されなくなったときにのみ表示されます。これは、ハードウェアの2相クロックのようなものです。 （Stracheyのアイデアで、McCarthyとは異なり、Lucidの影響を受けています。）
ご多幸を祈る、
アラン・ケイ
アランはすでにこの質問に回答しているので、これ以上回答しても意味がないように見えるかもしれません。しかし、アランはあなたが持っていたすべての質問に答えたわけではありません。
特に：
ここでは不透明で不変のインスタンスが奨励されていると言ってよいでしょうか？それとも、推奨されないのは直接の状態変化だけですか？たとえば、BankAccountクラスがある場合、GetBalance、Deposit、Withdrawのインスタンスメソッド/メッセージがあっても問題ありません。 SetBalanceインスタンスメソッド/メッセージがないことを確認してください。
ここでの答えは、プログラムを構造化するために高次の動作を使用していないということです。実際の金融サービスシステムでは、BankAccountクラスにDepositメソッドを設定しないでください。これは、コンピューターが発明される前の銀行の動作とはまったく異なるためです。 ATMが発明されたとき、ATMはテラーが銀行で行ったことを文字通り自動化する必要がありました。窓口の役割は、顧客にアカウントのステータスを通知することです。これを行うために、顧客は預金伝票を窓口に渡すなど、いくつかの方法でのみ窓口と対話することができます。
これらのオブジェクト（Teller、Deposit Slipなど）を直接具体化することにより、問題のドメインは、システム内のエンティティによって渡されたメッセージに従って構造化されます。
アカウント自体が役割を果たします。アカウントの概念は、資産、負債、収入、または経費に関連する資金の流入と流出のアカウントを文字通り意味します。会計システム、または会計士は、これらのフローを記録、保持、再現し、ある時点でのアカウントの財政状態を通知します。テラーによる最新のレポートは「今すぐ」と考えることができますが、実際にはそうではありません。それは、ある時点で会計士によって記述された実際の財政状態です。銀行に行くと、「今」であるかのような錯覚を抱くだけです。これは、通常、支払いを行う権限があるのはあなただけだからです。これは特に100年前に当てはまりましたが、今日多くの人々が自動支払いを行っており、残高スリップを保持している銀行に実際にいる間、口座が変更される可能性があります-残高スリップはタイムスタンプが記録された特定の時点についてのみ通知するためです。
何でこれが大切ですか？さて、トランザクションを記録するために何が必要かを自問してください。
顧客は、銀行からの領収書を含む、彼らが行ったすべての独自の内部監査ログを持っています。同様に、世銀は実施したすべての内容について、独自の内部監査ログを保持しています。銀行は常に複式簿記 を実行します。つまり、総勘定元帳と貸借対照表に取引が記録されます。これにより、銀行は調整を実行し、特定の会計期間（日次、週次、月次、四半期、年次、双方向）で帳簿を閉じるときに偽のエントリがないことを確認できます。 -毎年、何でも）。これは、記録されるものの記録がべき等であるべきであることも示唆しています。つまり、すべての一意のトランザクションをリストするプログラムを作成すると、内部監査ログに偽の重複があったとしても、べき等のトランザクション識別子がロギングメッセージに埋め込まれるため、そうすることができます。
自動支払いで口座から引き落としおよび入金できることを考えると、Accountantが予測を実行できることも理にかなっているようです。これは、コンピューターが会計システムに与える影響の実現でした。したがって、誰かが Resources-Events-Agents と呼ばれる会計システムスキームを発明しました。これは、過去を見るだけでなく、将来も見て、以前よりも細かい粒度でキャッシュフローを見積もることとより一致しました。基本的に、REAは従来の会計システムよりもメタデータが多いため、より良いレポートとビジネス分析が可能です。たとえば、「バリューチェーン」分析と「サプライチェーン」分析は、従来の会計では簡単なことではありません。
同様に、Agoric ComputingまたはSmart Contractsは、市場メカニズムからコンピューティングにアイデアをもたらします。預金伝票を提出するときは、預金する小切手または財布も提供することが重要です。小切手を受け取ってから実際にアカウントに入金されるまでにはリードタイムがあるため、通貨を安全に管理する方法が必要です。結局のところ、オブジェクト機能は、分散された安全な通貨を実現する自然な方法です。それらは、アリスがボブに小切手を書いた後ですべての資金を引き出すことによって、アリスがボブをだまさないようにするために使用できます。