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