Що мав на увазі Алан Кей під „завданням” у „Ранній історії малих розмов”?

Я читав "Ранню історію Малого розмови", і є кілька згадок про "завдання", які змушують мене поставити під сумнів своє розуміння його значення:

Хоча ООП виходив із багатьох мотивів, два були центральними. Великий масштаб полягав у тому, щоб знайти кращу модульну схему для складних систем, що передбачає приховування деталей, а маленький - знайти більш гнучку версію призначення, а потім спробувати її повністю усунути.

(з 1960-66 рр. - початок ООП та інші формаційні ідеї шістдесятих років , розділ І)

Що я отримав від Simula, це те, що ти тепер можеш замінити прив’язки та завдання цілями . Останнє, що ви хотіли зробити будь-якому програмісту, - це возитися з внутрішнім станом, навіть якщо його зображено образно. Натомість об'єкти повинні бути представлені як сайт поведінки вищого рівня, більш відповідний для використання в якості динамічних компонентів . (...) Прикро, що велика частина того, що сьогодні називається "об'єктно-орієнтоване програмування", - це просто програмування в старому стилі з вигадливішими конструкціями. Багато програм завантажені операціями "стилю призначення", які зараз виконуються за допомогою більш дорогих доданих процедур.

(від стилю "Об'єктно-орієнтований" , розділ IV)

Чи я правильно трактую наміри як те, що об'єкти мають бути фасадами, і будь-який метод (або "повідомлення"), метою якого є встановлення змінної екземпляра на об'єкт (тобто "призначення"), перемагає мету? Здається, що таке тлумачення підтримується двома пізнішими твердженнями в Розділі IV:

Чотири методи, які використовуються разом - стійкий стан, поліморфізм, інстанціювання та методи-цілі для об'єкта - приносять велику частину сили. Жоден із них не вимагає використання «об’єктно-орієнтованої мови» - ALGOL 68 майже може бути перетворений на цей стиль - і OOPL просто фокусує розум дизайнера в певному плідному напрямку. Однак виконання права на інкапсуляцію - це зобов'язання не просто абстрагувати стан, а усунути від програмування метафори, орієнтовані на стан.

... і:

Виписки про призначення, навіть абстрактні, - виражають цілі низького рівня, і для цього потрібно буде більше. Як правило, ми не хочемо, щоб програміст возився зі станом, модельований чи ні.

Чи було б справедливо сказати, що тут заохочуються непрозорі, незмінні випадки? Або це просто прямі зміни стану, які не відволікають? Наприклад, якщо у мене є BankAccountклас, нормально мати GetBalance, Depositа також Withdrawекземпляри методів / повідомлень; просто переконайтеся, що немає SetBalanceметоду / повідомлення екземпляра?

Основна ідея (під впливом Sketchpad) полягає в тому, що більшість змінних / значень знаходяться в динамічних взаємозв'язках - один з одним (підтримується внутрішністю об'єкта), тому можливість безпосередньо скинути значення ззовні небезпечно. Оскільки (у Smalltalk так чи інакше) необхідний принаймні метод встановлення, це дозволяє реалізувати внутрішню методику дії зовнішньої настройки для підтримки бажаних взаємозв'язків. Але більшість людей, які використовують сетери, просто використовують їх для імітації прямих призначень внутрішніх змінних, і це порушує дух і намір реального OOP.

Але об'єкти мають "світові лінії" змін у часі. Це можна розглядати як "історію" версій об'єкта, в якому співвідношення - узгоджуються. У цій схемі немає перегонових умов ... об'єкт видно лише тоді, коли він стабільний і більше не обчислює. Це як двофазний годинник в HW. (Ідея Страчі, і в іншому, ніж Маккарті, під впливом Люцида.)

Найкращі побажання,

Алан Кей

Я усвідомлюю, що Алан вже відповів на це питання, і тому може здатися, що дальше відповідати безглуздо. Однак Алан відповів не на кожне з вас питань.

Зокрема:

Чи було б справедливо сказати, що тут заохочуються непрозорі, незмінні випадки? Або це просто прямі зміни стану, які не відволікають? Наприклад, якщо у мене є клас BankAccount, нормально мати методи / повідомлення GetBalance, Deposit і Вивести екземпляр; просто переконайтесь, що немає методу / повідомлення екземпляра SetBalance?

Відповідь тут полягає в тому, що ви не використовуєте поведінку вищого порядку для структурування своєї програми. Системи фінансових послуг у реальному світі не повинні мати метод депозиту в класі BankAccount, оскільки це зовсім не так, як банки працювали до винаходу комп'ютерів! Коли банкомати були винайдені, їм довелося буквально автоматизувати те, що робив теллер у банку. Роль Продавця полягає в тому, щоб сповіщати клієнтів про стан їхнього рахунку. Для цього клієнту дозволяється взаємодіяти з Покупцем лише декількома способами, наприклад, передаючи платіж депозиту до Теллера.

Шляхом прямого перенаправлення цих об'єктів - Teller, Delip Slip тощо - проблемний домен структурується відповідно до повідомлень, що передаються суб'єктами в системі.

Сам Рахунок відіграє певну роль - ідея Рахунку буквально означає рахунок фінансових надходжень та відтоків стосовно активів, відповідальності, доходу або витрат. Система бухгалтерського обліку або Бухгалтер записує, зберігає та відтворює ці потоки та повідомляє про фінансовий стан рахунку у певний час. Останній звіт Теллера можна вважати "зараз", але насправді: це справді фінансове становище, як описано Бухгалтером у певний момент часу. Просто виникає ілюзія бути "зараз", коли ви йдете в банк, адже, як правило, ви єдиний, хто має право здійснювати платежі. Це було особливо вірно 100 років тому, але сьогодні багато людей мають автоматизовані платежі,

Чому це важливо? Ну, запитайте себе, що потрібно зробити, щоб записати транзакцію:

Клієнт має власний журнал внутрішнього аудиту всього, що він зробив, включаючи надходження від Банку. Так само Банк веде власний журнал внутрішнього аудиту щодо всього, що вони зробили. Банк завжди веде облік з подвійним записом , тобто реєструє операції в загальній книзі та балансі. Це дозволяє Банку здійснювати звіркуі переконайтесь, що немає підроблених записів, коли вони закривають свої книги за певний фінансовий період (щодня, щотижня, щомісяця, щокварталу, щорічно, щорічно, що завгодно). Це також говорить про те, що запис, що записується, повинен бути ідентичним. Значить, якби ми писали програму для переліку всіх унікальних транзакцій, ми могли б це зробити, навіть якщо в нашому журналі внутрішнього аудиту були помилкові дублікати, оскільки ми вставляли ідентифікаційні ідентифікатори транзакцій у повідомлення журналів.

Зважаючи на можливість автоматизованих платежів дебетувати та кредитувати ваш рахунок, схоже, має сенс, що бухгалтер також може робити прогнозування для вас. Це було усвідомленням впливу комп’ютерів на системи обліку. Відповідно, хтось винайшов схему системи бухгалтерського обліку під назвою " Ресурси-події-агенти", яка була більш узгоджена не тільки з поглядом на минуле, але і з поглядом на майбутнє та оцінкою грошових потоків з більш тонкою деталізацією, ніж раніше. По суті, REA - це просто більше метаданих, ніж класичні бухгалтерські системи, що дозволяє краще звітувати та аналізувати бізнес. Наприклад, аналіз "ланцюжка вартості" та аналіз "ланцюжка поставок" не є простим завданням для класичного обліку.

Так само Agoric Computing або Smart Contracts приносить ідеї від ринкових механізмів до обчислень. Важливо, що ви надаєте платіж за депозитом, ви також надаєте чек або гаманець для депозиту. Оскільки між отриманням чеку і фактичним надходженням до Вашого рахунку є провідний час, вам потрібен безпечний спосіб управління валютою. Як виявляється, об'єктні можливості - це природний спосіб досягти розподіленої захищеної валюти. Вони можуть бути використані для того, щоб Аліса не обдурила Боба, вилучивши всі її кошти після того, як вона написала Бобу цей чек.