Работа на объектно-ориентированномязыке(то есть на языке, который поддерживает наследование, пересылку сообщений и классы) не является ни необходимым, ни достаточным условием для того, чтобы заниматься объектно-ориентированнымпрограммированием. Как мы подчеркнули в главе1, наиболее важный аспект в ООП— техника проектирования, основанная на выделении и распределении обязанностей. Она
была названа проектированием на основе обязанностей или проектированием на основе ответственности (responsibility-driven design) [Wirfs-Brock 1989b, Wirfs-Brock 1990].
2.1. Ответственность подразумевает невмешательство
Как может констатировать любой, кто помнит себя ребенком(или кто воспитывает детей), ответственность— обоюдоострый меч. Когда вы заставляетекакой-либообъект(является ли он ребенком, или программной системой) быть ответственным за конкретные действия, вы ожидаете с его стороны определенного поведения, по крайней мере пока не нарушены правила. Но, в равной степени важно, что ответственность подразумевает определенный уровень независимости или невмешательства. Если вы скажете своей дочке, что она отвечает за уборку своей комнаты, вы, как правило, не стоите рядом с ней и не наблюдаете за выполнением работы— это противоречило бы понятию ответственности. Вместо этого вы рассчитываете, что после выдачи распоряжения будет получен желаемый результат.
Аналогично в случае примера с цветами из главы 1, когда я передаю запрос хозяйке цветочного магазина с просьбой переслать цветы, я не задумываюсь о том, как мой запрос будет обслужен. Хозяйка цветочного магазина, раз уж она взяла на себя ответственность, действует без вмешательства с моей стороны.
Разница между традиционным и объектно-ориентированнымпрограммированием во многих отношениях напоминает различие между активным наблюдением за тем, как ребенок выполняет работу, и передачей(делегированием) ребенку ответственности за эту деятельность. Традиционное программирование основывается в основном на приказанияхчему-либосделатьчто-то— к примеру, модифицировать запись или обновить массив данных. Тем самым фрагмент кода привязан посредством передачи управления и соглашений о структуре данных ко многим другим разделам программной системы. Такие зависимости могут возникать через использование глобальных переменных, значений указателей или попростуиз-занеправильного применения или зависимой реализации других фрагментов кода. Проектирование, основанное на ответственности, старается
отсекать эти связи или по крайней мере сделать их настолько слабыми, насколько это возможно.
С первого взгляда идея кажется не более сложной, чем понятия маскировки информации и модульности, которые важны при программировании в целом, в том числе и при использовании традиционных языков. Но проектирование, основанное на распределении ответственности, поднимает маскировку данных с уровня техники до уровня искусства.
Принцип маскировки информации становится жизненно важным при переходе от программирования «в малом» к программированию «в большом».
Одно из основных преимуществ ООП наблюдается, когда программные подсистемы многократно используются в разных проектах. Например, программа, управляющая моделированием(подобно той, которую мы будем разрабатывать в главе6), может имитировать как движение бильярдных шаров по столу, так и перемещение рыбы в цистернах. Эта способность кода к многократному использованию неявным образом подразумевает, что в программном обеспечении почти не должно быть проблемно- зависимых компонентов— оно должно полностью делегировать ответственность за специфичное поведение к фрагментам конкретной системы. Умению создавать подобный многократно используемый код не так просто научиться— оно требует опыта, тщательного исследования учебных примеров(парадигм, в исходном значении этого слова) и использования языков программирования, в которых такое делегирование является естественным и легко выражаемым. В последующих главах мы приведем несколько примеров.
2.2. Программирование «в малом» и «в большом»
О разработке индивидуального проекта часто говорят как о программировании «в малом», а о реализации большого проекта как о программировании «в большом».
Для программирования «в малом» характерны следующие признаки:
∙Код разрабатывается единственным программистом или, возможно, небольшой группой программистов. Отдельно взятый индивидуум может понять все аспекты проекта, от и до.
∙Основная проблема при разработке состоит в проектировании программы и написании алгоритмов для решения поставленной задачи.
Сдругой стороны, программирование «в большом» наделяет программный проект следующими свойствами:
∙Программная система разрабатывается большой командой программистов. При этом одна группа может заниматься проектированием(или спецификацией) системы, другая— осуществлять написание кода отдельных компонент, а третья— объединять фрагменты в конечный продукт. Нет единственного человека, который знал бы все о проекте.