Was meinte Alan Kay mit „Aufgabe“ in der frühen Geschichte von Smalltalk?

Ich habe die frühe Geschichte von Smalltalk gelesen und es gibt einige Erwähnungen von "Aufgaben", die mich dazu bringen, mein Verständnis ihrer Bedeutung in Frage zu stellen:

Obwohl OOP aus vielen Motivationen stammte, standen zwei im Mittelpunkt. Die große Aufgabe bestand darin, ein besseres Modulschema für komplexe Systeme zu finden, bei dem Details ausgeblendet wurden, und die kleine Aufgabe darin, eine flexiblere Version der Zuweisung zu finden und dann zu versuchen, sie insgesamt zu beseitigen.

( 1960-66 - Early OOP und andere prägende Ideen der sechziger Jahre , Sektion I)

Was ich von Simula bekommen habe, war, dass Sie jetzt Bindungen und Aufgaben durch Ziele ersetzen können . Das Letzte, was Sie von einem Programmierer erwarten, ist das Durcheinander mit dem internen Zustand, auch wenn er im übertragenen Sinne dargestellt wird. Stattdessen sollten die Objekte als Orte mit höherem Verhalten dargestellt werden, die für die Verwendung als dynamische Komponenten besser geeignet sind . (...) Es ist bedauerlich, dass vieles, was heute als "objektorientiertes Programmieren" bezeichnet wird, einfach altmodisches Programmieren mit schickeren Konstrukten ist. Viele Programme sind mit "Zuweisungsstil" -Operationen geladen, die jetzt durch teurere angehängte Prozeduren ausgeführt werden.

(aus "Objektorientierter" Stil , Abschnitt IV)

Stimmt es, dass ich die Absicht dahingehend interpretiere, dass Objekte als Fassaden gedacht sind, und dass eine Methode (oder "Nachricht"), mit der eine Instanzvariable für ein Objekt festgelegt werden soll (dh eine "Zuweisung"), den Zweck missachtet? Diese Interpretation scheint durch zwei spätere Aussagen in Abschnitt IV gestützt zu werden:

Vier Techniken, die zusammen verwendet werden - Dauerzustand, Polymorphismus, Instanziierung und Methoden als Ziele für das Objekt - machen einen Großteil der Kraft aus. Keines von diesen erfordert den Einsatz einer "objektorientierten Sprache" - ALGOL 68 kann fast auf diesen Stil umgestellt werden - und OOPL fokussiert lediglich den Verstand des Designers in eine bestimmte fruchtbare Richtung. Die richtige Kapselung ist jedoch nicht nur eine Verpflichtung zur Abstraktion des Staates, sondern auch zur Beseitigung zustandsorientierter Metaphern aus der Programmierung.

...und:

Zuweisungserklärungen - auch abstrakte - drücken sehr niedrige Ziele aus, von denen mehr benötigt werden, um etwas zu erreichen. Im Allgemeinen möchten wir nicht, dass der Programmierer mit dem Status herumspielt, ob simuliert oder nicht.

Wäre es fair zu sagen, dass hier undurchsichtige, unveränderliche Instanzen gefördert werden? Oder sind es einfach direkte Zustandsänderungen, die entmutigt werden? Wenn ich einen Zum Beispiel habe BankAccountKlasse, es ist OK zu haben GetBalance, Depositund WithdrawInstanz - Methoden / Nachrichten; nur sicherstellen, dass es keine SetBalanceInstanzmethode / -nachricht gibt?

Die Grundidee (beeinflusst von Sketchpad) ist, dass die meisten Variablen / Werte in dynamischen Beziehungen zueinander stehen (aufrechterhalten durch das Innere des Objekts), so dass es gefährlich ist, einen Wert direkt von außen zurücksetzen zu können. Da (in Smalltalk ohnehin) mindestens eine Setter-Methode erforderlich ist, kann die Möglichkeit einer externen Einstellungsaktion durch die interne Methode vermittelt werden, um die gewünschten Wechselbeziehungen aufrechtzuerhalten. Aber die meisten Leute, die Setter verwenden, simulieren damit einfach direkte Zuweisungen zu inneren Variablen, und dies verstößt gegen den Geist und die Absicht eines echten OOP.

Aber Objekte haben "Weltlinien" von Änderungen in der Zeit. Dies kann als eine Geschichte von Versionen des Objekts angesehen werden, in denen die Beziehungen übereinstimmen. In diesem Schema gibt es keine Rennbedingungen. Ein Objekt ist nur sichtbar, wenn es stabil ist und nicht mehr rechnet. Dies ist wie eine Zweiphasenuhr in HW. (Idee von Strachey und in einer anderen als von McCarthy und beeinflusst von Lucid.)

Die besten Wünsche,

Alan Kay

Mir ist klar, dass Alan diese Frage bereits beantwortet hat und es daher möglicherweise sinnlos erscheint, weiter darauf zu antworten. Alan beantwortete jedoch nicht jede Ihrer Fragen.

Speziell:

Wäre es fair zu sagen, dass hier undurchsichtige, unveränderliche Instanzen gefördert werden? Oder sind es einfach direkte Zustandsänderungen, die entmutigt werden? Wenn ich beispielsweise eine BankAccount-Klasse habe, ist es in Ordnung, Instanzmethoden / -nachrichten für GetBalance, Deposit und Withdraw zu verwenden. Stellen Sie einfach sicher, dass keine SetBalance-Instanzmethode / -Nachricht vorhanden ist.

Die Antwort hier ist, dass Sie kein Verhalten höherer Ordnung verwenden, um Ihr Programm zu strukturieren. Reale Finanzdienstleistungssysteme sollten keine Einzahlungsmethode für eine BankAccount-Klasse haben, da Banken vor der Erfindung von Computern so überhaupt nicht arbeiteten! Als Geldautomaten erfunden wurden, mussten sie buchstäblich automatisieren, was ein Teller in der Bank tat. Die Rolle eines Tellers wäre es, Kunden über den Status ihres Kontos zu informieren. Zu diesem Zweck kann der Kunde auf nur wenige Arten mit dem Kassierer interagieren, z. B. indem er dem Kassierer einen Einzahlungsschein aushändigt.

Durch die direkte Überprüfung dieser Objekte (Teller, Einzahlungsschein usw.) wird die Problemdomäne gemäß den von Entitäten im System übergebenen Nachrichten strukturiert.

Ein Konto selbst spielt eine Rolle - die Idee eines Kontos bedeutet wörtlich ein Konto der finanziellen Zu- und Abflüsse in Bezug auf einen Vermögenswert, eine Verbindlichkeit, Einnahmen oder Ausgaben. Ein Buchhaltungssystem oder ein Buchhalter erfasst, speichert und reproduziert diese Abläufe und teilt Ihnen die Finanzlage des Kontos zu einem bestimmten Zeitpunkt mit. Der letzte Bericht des Erzählers kann als "im Moment" betrachtet werden, aber nicht wirklich: Es ist wirklich die finanzielle Situation, wie sie der Buchhalter zu einem bestimmten Zeitpunkt beschrieben hat. Es hat nur die Illusion, "jetzt" zu sein, wenn Sie zur Bank gehen, denn im Allgemeinen sind Sie der einzige, der berechtigt ist, Zahlungen zu leisten. Dies galt vor 100 Jahren besonders, aber heute haben viele Menschen automatisierte Zahlungen,

Warum ist das wichtig? Fragen Sie sich, was Sie tun müssen, um eine Transaktion aufzuzeichnen:

Der Kunde verfügt über ein eigenes internes Auditprotokoll über alle von ihm durchgeführten Aktivitäten, einschließlich der Einnahmen von der Bank. Ebenso führt die Bank ein eigenes internes Revisionsprotokoll über alles, was sie getan hat. Die Bank immer tut doppelte Buchführung , sie werden die Transaktionen in dem Blatt General Ledger und Gleichgewicht bedeutet. Dies ermöglicht der Bank eine Abstimmungund stellen Sie sicher, dass es keine falschen Einträge gibt, wenn sie ihre Bücher für einen bestimmten Finanzzeitraum schließen (täglich, wöchentlich, monatlich, vierteljährlich, jährlich, halbjährlich, was auch immer). Dies legt auch nahe, dass der Datensatz für das, was aufgezeichnet wird, idempotent sein sollte. Das heißt, wenn wir ein Programm schreiben würden, um alle eindeutigen Transaktionen aufzulisten, könnten wir dies auch dann tun, wenn sich falsche Duplikate in unserem internen Überwachungsprotokoll befinden, weil wir in die Protokollierungsnachrichten idempotente Transaktionskennungen eingebettet haben.

Angesichts der Möglichkeit automatisierter Zahlungen, Ihr Konto zu belasten und gutzuschreiben, erscheint es sinnvoll, dass der Buchhalter auch Prognosen für Sie erstellen kann. Dies war die Erkenntnis, welche Auswirkungen Computer auf Abrechnungssysteme haben können. Dementsprechend hat jemand ein Abrechnungssystem mit dem Namen Resources-Events-Agents erfunden, bei dem nicht nur die Vergangenheit, sondern auch die Zukunft im Blick und die Schätzung der Cashflows präziser als zuvor war. Im Wesentlichen besteht REA nur aus mehr Metadaten als bei klassischen Buchhaltungssystemen, was eine bessere Berichterstellung und Geschäftsanalyse ermöglicht. Beispielsweise sind die Analyse der Wertschöpfungskette und die Analyse der Lieferkette mit der klassischen Rechnungslegung nicht einfach zu bewerkstelligen.

Ebenso bringt Agoric Computing oder Smart Contracts Ideen von Marktmechanismen in das Computing ein. Es ist wichtig, dass Sie bei Vorlage eines Einzahlungsscheins auch einen Scheck oder eine Geldbörse zur Einzahlung bereitstellen. Da zwischen dem Erhalt des Schecks und dem tatsächlichen Eintreffen auf Ihrem Konto eine Vorlaufzeit liegt, benötigen Sie eine sichere Methode zur Währungsverwaltung. Wie sich herausstellt, sind Objektfunktionen ein natürlicher Weg, um eine verteilte sichere Währung zu erreichen. Sie können verwendet werden, um sicherzustellen, dass Alice Bob nicht betrügt, indem sie ihr gesamtes Geld abhebt, nachdem sie Bob diesen Scheck geschrieben hat.