Я читал «Раннюю историю Smalltalk», и есть несколько упоминаний о «назначении», которые заставляют меня усомниться в моем понимании его значения:
Хотя ООП исходило из многих мотивов, два были центральными. Крупномасштабная задача заключалась в том, чтобы найти лучшую модульную схему для сложных систем, связанных с сокрытием деталей, а мелкомасштабная - найти более гибкую версию назначения, а затем попытаться полностью ее исключить.
(с 1960-66 - Ранние ООП и другие формирующие идеи шестидесятых , Раздел I)
Что я получил от Симулы, так это то, что теперь вы можете заменить привязки и назначения целями . Последнее, что вы хотели, чтобы любой программист делал, - это связывайтесь с внутренним состоянием, даже если оно представлено в переносном смысле. Вместо этого объекты должны быть представлены как сайты поведения более высокого уровня, более подходящие для использования в качестве динамических компонентов . (...) К сожалению, большая часть того, что сегодня называют «объектно-ориентированным программированием», является просто программированием старого стиля с более изощренными конструкциями. Многие программы загружаются операциями «стиля назначения», которые теперь выполняются с помощью более дорогих вложенных процедур.
(из «Объектно-ориентированного» стиля , раздел IV)
Правильно ли я интерпретировать намерение как то, что объекты должны быть фасадами, и любой метод (или «сообщение»), цель которого состоит в том, чтобы установить переменную экземпляра для объекта (т. Е. «Назначение»), побеждает цель? Такое толкование подтверждается двумя более поздними утверждениями в разделе IV:
Четыре техники, используемые вместе - постоянное состояние, полиморфизм, создание экземпляров и методы как цели для объекта - составляют большую часть власти. Ни один из них не требует использования «объектно-ориентированного языка» - ALGOL 68 почти можно использовать в этом стиле - а OOPL просто фокусирует внимание дизайнера на конкретном плодотворном направлении. Однако правильная инкапсуляция - это обязательство не только абстрагировать состояние, но и исключить ориентированные на состояние метафоры из программирования.
...а также:
Заявления о назначении - даже абстрактные - выражают цели очень низкого уровня, и для их выполнения потребуется больше таких целей. Как правило, мы не хотим, чтобы программист возился с состоянием, моделируемым или нет.
Будет ли справедливым сказать, что здесь поощряются непрозрачные, неизменные случаи? Или это просто прямые изменения состояния, которые не поощряются? Например, если у меня есть BankAccountкласс, все в порядке GetBalance, Depositи Withdrawметоды / сообщения экземпляра; просто убедитесь, что нет SetBalanceметода / сообщения экземпляра?
источник
Я понимаю, что Алан уже ответил на этот вопрос, и поэтому может показаться, что бессмысленно отвечать дальше. Однако Алан ответил не на все ваши вопросы.
В частности:
Ответ здесь заключается в том, что вы не используете поведение более высокого порядка для структурирования вашей программы. Реальные системы финансовых услуг не должны иметь метод Deposit для класса BankAccount, потому что это совсем не то, как банки работали до изобретения компьютеров! Когда были изобретены банкоматы, они должны были буквально автоматизировать действия кассира в банке. Роль кассира заключается в том, чтобы уведомлять клиентов о состоянии их учетной записи. Для этого клиенту разрешается взаимодействовать с кассиром только несколькими способами, например, передавать депозитный чек кассиру.
Путем прямого сопоставления этих объектов - Teller, Deposit Slip и т. Д. - проблемный домен структурируется в соответствии с сообщениями, передаваемыми объектами в системе.
Сама Учетная запись играет роль - сама идея Учетной записи буквально означает учетную запись финансовых притоков и оттоков активов, пассивов, доходов или расходов. Система бухгалтерского учета, или бухгалтер, регистрирует, сохраняет и воспроизводит эти потоки и сообщает вам о финансовом положении счета в определенный момент времени. Самый последний отчет Теллера можно рассматривать как «прямо сейчас», но не совсем: это действительно финансовое положение, описанное Бухгалтером в определенный момент времени. У него просто есть иллюзия «прямо сейчас», когда вы идете в банк, потому что, как правило, вы единственный, кто уполномочен осуществлять платежи. Это было особенно верно 100 лет назад, но сегодня многие люди имеют автоматические платежи,
Почему это важно? Ну, спросите себя, что нужно сделать для записи транзакции:
Клиент имеет собственный журнал внутреннего аудита всего, что он сделал, включая квитанции от Банка. Кроме того, Банк ведет собственный журнал внутреннего аудита всего, что они сделали. Банк всегда ведет учет с двумя записями, то есть он записывает операции в Главной книге и бухгалтерском балансе. Это позволяет банку проводить сверкуи убедитесь, что нет никаких ложных записей, когда они закрывают свои книги на данный финансовый период (ежедневно, еженедельно, ежемесячно, ежеквартально, раз в два года, что угодно). Это также предполагает, что запись о том, что записывается, должна быть идемпотентной. Это означает, что если бы мы написали программу для перечисления всех уникальных транзакций, мы могли бы сделать это, даже если бы в нашем журнале внутреннего аудита были ложные дубликаты, потому что мы встраивали идентификаторы идемпотентных транзакций в сообщения регистрации.
Учитывая возможность автоматических платежей для дебетования и зачисления на ваш счет, кажется, имеет смысл, что бухгалтер может также делать прогнозирование для вас. Это было осознанием того влияния, которое компьютеры могут оказать на системы учета. Соответственно, кто-то изобрел схему системы бухгалтерского учета под названием « Ресурсы-События-Агенты», которая была более встроенной, чтобы не просто смотреть в прошлое, но также смотреть в будущее и оценивать денежные потоки с более высокой степенью детализации, чем раньше. По сути, REA - это просто больше метаданных, чем классические учетные системы, что позволяет лучше составлять отчеты и анализировать бизнес. Например, анализ «цепочки создания стоимости» и «цепочки поставок» не так просты для классического учета.
Аналогичным образом, Agoric Computing или Smart Contracts переносят идеи с рыночных механизмов на вычисления. Важно, чтобы, предоставляя бланк депозита, вы также предоставили чек или кошелек для депозита. Поскольку между получением чека и его фактическим поступлением на ваш счет существует определенное время, вам необходим безопасный способ управления валютой. Как выясняется, объектные возможности являются естественным способом достижения распределенной безопасной валюты. Они могут быть использованы для того, чтобы Алиса не обманула Боба, сняв все свои средства после того, как написала Бобу этот чек.
источник
BankAccountпример игрушек ООП .