Сообщения должны выражать возможности, а не запрашивать информацию
Объектно-ориентированные и структурные системы склонны подходить к проблемам с диаметрально противоположных направлений. Возьмите в качестве примера скромную запись employee. В структурных системах вы бы использовали тип struct и имели бы доступ к полям этого типа повсюду из своей программы. Например, код для печати записи мог бы свободно повторяться в нескольких сотнях мест программы. Если вы меняете что-то в основе, вроде изменения типа поля name с массива char на 16-битные символы Unicode, то вы должны разыскать каждую ссылку на name и модифицировать ее для работы с новым типом.
В хорошо спроектированной объектно-ориентированной системе было бы невозможно получить доступ к полю name.4
Позвольте мне повторить это, потому что эта концепция так фундаментальна: невозможно получить доступ к полю внутри объекта, даже такому простому, как name в объекте employee. Скорее всего вы попросите employee
проявить какую-нибудь способность, такую как "напечатать себя", "сохранить себя в базе данных" или "модифицировать себя, взаимодействуя с пользователем". В этом последнем случае обработчик сообщений вывел бы диалоговое окно, которое бы использовалось пользователем для ввода или изменения данных.
Главным преимуществом этого подхода является то, что отправитель сообщения может меньше волноваться о том, как организовано внутреннее хранение данных. Пока объект может себя печатать, модифицировать или делать что-нибудь еще —
проблемы нет. Вы можете перевести name на Unicode, не затрагивая отправителя сообщения. Этот вопрос рассматривается далее во многих правилах этой главы книги.
