Бьерн Страуструп.
Язык программирования С++
308
учитывать) повредит проекту. Сложность задачи не уменьшится, но, поскольку система реализована на
обедненном языке, структура программы плохо будет отвечать проекту. У
нее слишком большой
объем, не хватает проверки типов, и, вообще, она плохо приспособлена для использования различных
вспомогательных средств. Это путь, приводящий к кошмарам при ее сопровождении.
Обычно для преодоления указанных трудностей создают специальные средства, поддерживающие
понятия, используемые в проекте. Благодаря им создаются конструкции более высокого уровня и
организуются проверки с целью компенсировать дефекты (или сознательное обеднение) языка
реализации. Так метод проектирования становится самоцелью, и для него создается специальный язык
программирования. Такие языки программирования в большинстве случаев являются плохой заменой
широко распространенных языков программирования общего назначения, которые сопровождаются
подходящими средствами проектирования. Использовать С++ с
таким ограничением, которое должно
компенсироваться при проектировании специальными средствами, бессмысленно. Хотя несоответствие
между языком программирования и средствами проектирования может быть просто стадией процесса
перехода, а значит временным явлением.
Самой типичной причиной игнорирования классов при проектировании является простая инерция.
Традиционные языки программирования не предоставляют понятия класса, и в традиционных методах
проектирования отражаются этот недостаток. Обычно в процессе проектирования наибольшее
внимание уделяется разбиению задачи на процедуры, производящие требуемые действия. В главе 1
это
понятие называлось процедурным программированием, а в области проектирования оно именуется
как функциональная декомпозиция. Возникает типичный вопрос "Можно ли использовать С++
совместно с методом проектирования, базирующимся на
функциональной декомпозиции?" Да, можно,
но, вероятнее всего, в результате вы придете к использованию С++ как просто улучшенного С со всеми
указанными выше проблемами. Это может быть приемлемо на период перехода на новый язык, или для
уже завершенного проектирования, или для подзадач, в которых использование классов не дает
существенных выгод (если учитывать опыт программирования на С++ к данному моменту), но в общем
случае на большом отрезке времени отказ от свободного использования классов, связанный с методом
функциональной декомпозиции, никак не совместим с эффективным использованием С++.
Процедурно-ориентированный
и
объектно-ориентированный
подходы
к
программированию
различаются по своей сути и обычно ведут к совершенно разным решениям одной задачи. Этот вывод
верен как для стадии реализации, так и для стадии проектирования: вы концентрируете внимание или
на предпринимаемых действиях, или на представляемых сущностях, но не на том и другом
одновременно.
Тогда почему
метод объектно-ориентированного проектирования предпочтительнее метода
функциональной декомпозиции? Главная причина в том, что функциональная декомпозиция не дает
достаточной абстракции данных. А отсюда уже следует, что проект будет
-
менее податливым к изменениям,
-
менее приспособленным для использования различных вспомогательных средств,
-
менее пригодным для параллельного развития и
-
менее пригодным для параллельного выполнения.
Дело в том, что
функциональная декомпозиция вынуждает объявлять "важные" данные глобальными,
поскольку, если система структурирована как дерево функций, всякое данное, доступное двум
функциям, должно быть глобальным по отношению к ним. Это приводит к тому, что "важные" данные
"всплывают" к вершине дерева, по мере того как все большее число функций требует доступа к ним.
В точности так же происходит в случае иерархии классов с
одним корнем, когда "важные" данные
всплывают по направлению к базовому классу.
Когда мы концентрируем внимание на описаниях классов, заключающих определенные данные в
оболочку, то зависимости между различными частями программы выражены явно и можно их
проследить. Еще более важно то, что при таком подходе уменьшается число зависимостей в системе за
счет лучшей расстановки ссылок на данные.
Однако, некоторые задачи лучше решаются с помощью набора процедур. Смысл "объектно-
ориентированного" проектирования не в том, чтобы удалить все глобальные процедуры из программы
или не иметь в системе процедурно-ориентированных частей. Основная идея скорее в том, что классы,
Бьерн Страуструп.
Язык программирования С++
309
а не глобальные процедуры становятся главным объектом внимания на стадии проектирования.
Использование процедурного стиля должно быть осознанным решением, а не решением, принимаемым
по умолчанию. Как классы, так и процедуры следует применять сообразно области приложения, а не
просто как неизменные методы проектирования.
Достарыңызбен бөлісу: