Co Alan Kay miał na myśli przez „zadanie” we wczesnej historii Smalltalk?

Czytałem Wczesną historię Smalltalk i jest kilka wzmianek o „zadaniu”, które każą mi podważyć moje rozumienie jego znaczenia:

Chociaż OOP pochodzi z wielu motywacji, dwie były kluczowe. Na dużą skalę należało znaleźć lepszy schemat modułów dla złożonych systemów obejmujących ukrywanie szczegółów, a na małą skalę - znaleźć bardziej elastyczną wersję przypisania, a następnie spróbować całkowicie ją wyeliminować.

(od 1960–66 - wczesne OOP i inne kształtujące idee lat sześćdziesiątych , sekcja I)

To, co otrzymałem od Simuli, to to, że możesz teraz zastąpić wiązania i zadania celami . Ostatnią rzeczą, którą chciałbyś, aby każdy programista zrobił, to bałagan ze stanem wewnętrznym, nawet jeśli jest przedstawiony w przenośni. Zamiast tego obiekty należy przedstawić jako miejsce zachowań wyższego poziomu, bardziej odpowiednie do wykorzystania jako komponenty dynamiczne . (...) Niestety, większość tego, co dziś nazywa się „programowaniem obiektowym”, to po prostu programowanie w starym stylu z bardziej wyszukanymi konstrukcjami. Wiele programów jest obciążonych operacjami typu „przypisania”, wykonywanymi teraz przez droższe dołączone procedury.

(ze stylu „obiektowego” , sekcja IV)

Czy mam rację, interpretując intencję, że obiekty mają być fasadami, a jakakolwiek metoda (lub „wiadomość”), której celem jest ustawienie zmiennej instancji na obiekcie (tj. „Przypisanie”), pokonuje cel? Ta interpretacja wydaje się poparta dwoma późniejszymi stwierdzeniami w sekcji IV:

Cztery techniki zastosowane razem - stan trwały, polimorfizm, tworzenie instancji i metody jako cele dla obiektu - stanowią znaczną część mocy. Żadne z nich nie wymaga zastosowania „języka obiektowego” - ALGOL 68 można niemal odwrócić do tego stylu - a OOPL jedynie skupia umysł projektanta w konkretnym owocnym kierunku. Jednak robienie prawa do enkapsulacji jest zobowiązaniem nie tylko do abstrakcji stanu, ale także do wyeliminowania zorientowanych na państwo metafor w programowaniu.

...i:

Opisy zadań - nawet abstrakcyjne - wyrażają cele na bardzo niskim poziomie, a więcej z nich będzie potrzebnych, aby cokolwiek zrobić. Zasadniczo nie chcemy, aby programista bałaganował stanem, czy był symulowany czy nie.

Czy uczciwie byłoby powiedzieć, że zachęca się tu do tworzenia nieprzejrzystych, niezmiennych przypadków? Czy odradza się po prostu bezpośrednie zmiany stanu? Na przykład, jeśli mam BankAccountklasę, to OK, aby mieć GetBalance, Depositi Withdrawmetody instancji / komunikaty; upewnij się, że nie ma SetBalancemetody / komunikatu instancji?

Podstawową ideą (na którą wpływa Sketchpad) jest to, że większość zmiennych / wartości znajduje się w relacji dynamicznej ze sobą (utrzymywanej przez wnętrze obiektu), więc możliwość bezpośredniego resetowania wartości z zewnątrz jest niebezpieczna. Ponieważ (w każdym razie w Smalltalk) wymagana jest co najmniej metoda ustawiająca, pozwala to na możliwość pośredniczenia w działaniu zewnętrznym przez metodę wewnętrzną w celu utrzymania pożądanych powiązań. Ale większość ludzi używających seterów po prostu używa ich do symulacji bezpośrednich przypisań do zmiennych wewnętrznych, a to narusza ducha i zamiary prawdziwego OOP.

Ale obiekty mają „linie świata” zmian w czasie. Można to traktować jako „historię” wersji obiektu, w których relacje są zgodne. W tym schemacie nie ma warunków wyścigu ... obiekt jest widoczny tylko wtedy, gdy jest stabilny i nie jest już przetwarzany. To jest jak dwufazowy zegar w HW. (Pomysł ze Strachey, w innym niż McCarthy i pod wpływem Lucid.)

Wszystkiego najlepszego,

Alan Kay

Zdaję sobie sprawę, że Alan już odpowiedział na to pytanie, więc może się wydawać, że dalsza odpowiedź nie ma sensu. Alan nie odpowiedział jednak na każde pytanie.

W szczególności:

Czy uczciwie byłoby powiedzieć, że zachęca się tu do tworzenia nieprzejrzystych, niezmiennych przypadków? Czy odradza się po prostu bezpośrednie zmiany stanu? Na przykład, jeśli mam klasę BankAccount, mogę mieć metody / komunikaty instancji GetBalance, Depozyt i Wypłata; po prostu upewnij się, że nie ma metody / komunikatu instancji SetBalance?

Odpowiedź tutaj jest taka, że ​​nie używasz zachowań wyższego rzędu do strukturyzowania programu. Systemy usług finansowych w świecie rzeczywistym nie powinny mieć metody depozytu w klasie BankAccount, ponieważ tak nie działały banki przed wynalezieniem komputerów! Kiedy wynaleziono bankomaty, musiały one dosłownie zautomatyzować to, co bankomat zrobił w banku. Rolą kasjera byłoby powiadamianie klientów o statusie ich konta. Aby to zrobić, klient może wchodzić w interakcje z kasjerem tylko na kilka sposobów, na przykład przekazać kupon depozytowy kasjerowi.

Dzięki bezpośredniej reifikacji tych obiektów - kasjerowi, kuponowi depozytów itp. - domena problemu jest uporządkowana zgodnie z komunikatami przekazywanymi przez podmioty w systemie.

Sam rachunek odgrywa rolę - jego koncepcja dosłownie oznacza rachunek wpływów i wypływów finansowych w odniesieniu do aktywów, pasywów, dochodów lub wydatków. System rachunkowości lub księgowy rejestruje, zachowuje i powiela te przepływy oraz informuje o sytuacji finansowej konta w danym momencie. Najnowszy raport Teller można uznać za „teraz”, ale nie do końca: tak naprawdę jest to sytuacja finansowa opisana przez księgowego w danym momencie. Ma tylko złudzenie bycia „teraz”, kiedy idziesz do banku, ponieważ ogólnie jesteś jedynym uprawnionym do dokonywania płatności. Było to szczególnie prawdziwe 100 lat temu, ale dziś wiele osób ma płatności automatyczne,

Dlaczego to jest ważne? Zadaj sobie pytanie, co należy zrobić, aby zarejestrować transakcję:

Klient ma własny dziennik kontroli wewnętrznej wszystkiego, co zrobił, w tym pokwitowania z Banku. Podobnie, Bank prowadzi własny dziennik kontroli wewnętrznej wszystkiego, co zrobił. Bank zawsze prowadzi rachunkowość podwójnego zapisu , co oznacza, że ​​rejestruje transakcje w księdze głównej i bilansie. Pozwala to bankowi na dokonanie uzgodnieniai upewnij się, że nie ma fałszywych wpisów, gdy zamykają książki na dany okres finansowy (codziennie, co tydzień, co miesiąc, co kwartał, co rok, co dwa lata, cokolwiek). Sugeruje to również, że zapis tego, co zostanie nagrane, powinien być idempotentny. Oznacza to, że gdybyśmy napisali program z listą wszystkich unikatowych transakcji, moglibyśmy to zrobić, nawet jeśli fałszywe duplikaty byłyby w naszym wewnętrznym dzienniku kontroli, ponieważ w komunikatach logowania osadziliśmy idempotentne identyfikatory transakcji.

Biorąc pod uwagę możliwość automatycznych płatności w celu obciążenia i uznania twojego konta, wydaje się sensowne, aby Księgowy mógł również wykonać dla Ciebie prognozy . Była to świadomość wpływu, jaki komputery mogą mieć na systemy księgowe. W związku z tym ktoś wymyślił system systemu księgowania o nazwie Resources-Events-Agents, który był bardziej zgodny nie tylko z patrzeniem na przeszłość, ale także z myślą o przyszłości i szacowaniu przepływów pieniężnych na bardziej szczegółowym poziomie niż wcześniej. Zasadniczo REA to tylko więcej metadanych niż klasyczne systemy księgowe, co pozwala na lepsze raportowanie i analizy biznesowe. Na przykład analiza „łańcucha wartości” i analiza „łańcucha dostaw” nie są łatwe do zrobienia w klasycznej rachunkowości.

Podobnie, Agoric Computing lub Smart Contracts przenosi pomysły z mechanizmów rynkowych do informatyki. Ważne jest, aby dostarczając kupon depozytowy, dostarczyć również czek lub torebkę do złożenia. Ponieważ między otrzymaniem Czeki a faktycznym wejściem na Twoje konto upływa czas oczekiwania, potrzebujesz bezpiecznego sposobu zarządzania walutą. Jak się okazuje, możliwości obiektu są naturalnym sposobem na uzyskanie bezpiecznej waluty rozproszonej. Można ich użyć, aby upewnić się, że Alice nie oszuka Boba, wypłacając wszystkie jej fundusze po tym, jak napisała Bobowi ten czek.