Б. Страуструп - Язык программирования С++ (1119446), страница 86
Текст из файла (страница 86)
Здесь естьсвои преимущества. Например, получившееся в результате строгое разделение данных и программногокода позволяет легко использовать традиционные базы данных, которые разработаны для такихпрограмм. Поскольку используется ограниченный язык программирования, от программистов требуетсяменьше опытности (или, по крайней мере другой ее уровень). Для многих приложений, например, длятрадиционных баз данных, работающих с файлом последовательно, такой подход вполне разумен, атрадиционные приемы, отработанные за десятилетия, вполне адекватны задаче.Однако там, где область приложения существенно отличается от традиционной последовательнойобработки записей (или символов), или сложность задачи выше, как, например, в диалоговой системеCASE, недостаток языковой поддержки абстрактных данных из-за отказа от классов (если их не307Бьерн Страуструп.Язык программирования С++учитывать) повредит проекту.
Сложность задачи не уменьшится, но, поскольку система реализована наобедненном языке, структура программы плохо будет отвечать проекту. У нее слишком большойобъем, не хватает проверки типов, и, вообще, она плохо приспособлена для использования различныхвспомогательных средств. Это путь, приводящий к кошмарам при ее сопровождении.Обычно для преодоления указанных трудностей создают специальные средства, поддерживающиепонятия, используемые в проекте. Благодаря им создаются конструкции более высокого уровня иорганизуются проверки с целью компенсировать дефекты (или сознательное обеднение) языкареализации. Так метод проектирования становится самоцелью, и для него создается специальный языкпрограммирования. Такие языки программирования в большинстве случаев являются плохой заменойшироко распространенных языков программирования общего назначения, которые сопровождаютсяподходящими средствами проектирования.
Использовать С++ с таким ограничением, которое должнокомпенсироваться при проектировании специальными средствами, бессмысленно. Хотя несоответствиемежду языком программирования и средствами проектирования может быть просто стадией процессаперехода, а значит временным явлением.Самой типичной причиной игнорирования классов при проектировании является простая инерция.Традиционные языки программирования не предоставляют понятия класса, и в традиционных методахпроектирования отражаются этот недостаток. Обычно в процессе проектирования наибольшеевнимание уделяется разбиению задачи на процедуры, производящие требуемые действия.
В главе 1это понятие называлось процедурным программированием, а в области проектирования оно именуетсякак функциональная декомпозиция. Возникает типичный вопрос "Можно ли использовать С++совместно с методом проектирования, базирующимся на функциональной декомпозиции?" Да, можно,но, вероятнее всего, в результате вы придете к использованию С++ как просто улучшенного С со всемиуказанными выше проблемами. Это может быть приемлемо на период перехода на новый язык, или дляуже завершенного проектирования, или для подзадач, в которых использование классов не даетсущественных выгод (если учитывать опыт программирования на С++ к данному моменту), но в общемслучае на большом отрезке времени отказ от свободного использования классов, связанный с методомфункциональной декомпозиции, никак не совместим с эффективным использованием С++.Процедурно-ориентированный и объектно-ориентированный подходы к программированиюразличаются по своей сути и обычно ведут к совершенно разным решениям одной задачи.
Этот выводверен как для стадии реализации, так и для стадии проектирования: вы концентрируете внимание илина предпринимаемых действиях, или на представляемых сущностях, но не на том и другомодновременно.Тогда почему метод объектно-ориентированного проектирования предпочтительнее методафункциональной декомпозиции? Главная причина в том, что функциональная декомпозиция не даетдостаточной абстракции данных. А отсюда уже следует, что проект будет-менее податливым к изменениям,-менее приспособленным для использования различных вспомогательных средств,-менее пригодным для параллельного развития и-менее пригодным для параллельного выполнения.Дело в том, что функциональная декомпозиция вынуждает объявлять "важные" данные глобальными,поскольку, если система структурирована как дерево функций, всякое данное, доступное двумфункциям, должно быть глобальным по отношению к ним.
Это приводит к тому, что "важные" данные"всплывают" к вершине дерева, по мере того как все большее число функций требует доступа к ним.В точности так же происходит в случае иерархии классов с одним корнем, когда "важные" данныевсплывают по направлению к базовому классу.Когда мы концентрируем внимание на описаниях классов, заключающих определенные данные воболочку, то зависимости между различными частями программы выражены явно и можно ихпроследить. Еще более важно то, что при таком подходе уменьшается число зависимостей в системе засчет лучшей расстановки ссылок на данные.Однако, некоторые задачи лучше решаются с помощью набора процедур. Смысл "объектноориентированного" проектирования не в том, чтобы удалить все глобальные процедуры из программыили не иметь в системе процедурно-ориентированных частей.
Основная идея скорее в том, что классы,308Бьерн Страуструп.Язык программирования С++а не глобальные процедуры становятся главным объектом внимания на стадии проектирования.Использование процедурного стиля должно быть осознанным решением, а не решением, принимаемымпо умолчанию. Как классы, так и процедуры следует применять сообразно области приложения, а непросто как неизменные методы проектирования.12.1.2 Игнорирование наследованияРассмотрим вариант 2 - проект, который игнорирует наследование. В этом случае в окончательнойпрограмме просто не используются возможности основного средства С++, хотя и получаютсяопределенные выгоды при использовании С++ по сравнению с использованием языков С, Паскаль,Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции, утверждения, что"наследование - это деталь реализации", или "наследование препятствует упрятыванию информации",или "наследование затрудняет взаимодействие с другими системами программирования".Считать наследование всего лишь деталью реализации – значит игнорировать иерархию классов,которая может непосредственно моделировать отношения между понятиями в области приложения.Такие отношения должны быть явно выражены в проекте, чтобы дать возможность разработчикупродумать их.Сильные доводы можно привести в пользу исключения наследования из тех частей программы на С++,которые непосредственно взаимодействуют с программами, написанными на других языках.
Но это неявляется достаточной причиной, чтобы отказаться от наследования в системе в целом, это простодовод в пользу того, чтобы аккуратно определить и инкапсулировать программный интерфейс с"внешним миром". Аналогично, чтобы избавиться от беспокойства, вызванного путаницей супрятыванием информации при наличии наследования, надо осторожно использовать виртуальныефункции и закрытые члены, но не отказываться от наследования.Существует достаточно много ситуаций, когда использование наследования не дает явных выгод, нополитика "никакого наследования" приведет к менее понятной и менее гибкой системе, в которойнаследование "подделывается" с помощью более традиционных конструкций языка и проектирования.Для больших проектов это существенно. Более того, вполне возможно, что несмотря на такую политику,наследование все равно будет использоваться, поскольку программисты, работающие на С++, найдутубедительные доводы в пользу проектирования с учетом наследования в различных частях системы.Таким образом, политика "никакого наследования" приведет лишь к тому, что в системе будетотсутствовать целостная общая структура, а использование иерархии классов будет ограниченоопределенными подсистемами.Иными словами, будьте непредубежденными.
Иерархия классов не является обязательной частьювсякой хорошей программы, но есть масса ситуаций, когда она может помочь как в понимании областиприложения, так и в формулировании решений. Утверждение, что наследование может неправильноили чрезмерно использоваться, служит только доводом в пользу осторожности, а вовсе не в пользуотказа от него.12.1.3 Игнорирование статического контроля типовРассмотрим вариант 3, относящийся к проекту, в котором игнорируется статический контроль типов.Распространенные доводы в пользу отказа на стадии проектирования от статического контроля типовсводятся к тому, что "типы - это продукт языков программирования", или что "более естественнорассуждать об объектах, не заботясь о типах", или "статический контроль типов вынуждает нас думать ореализации на слишком раннем этапе". Такой подход вполне допустим до тех пор, пока он работает ине приносит вреда. Вполне разумно на стадии проектирования не заботиться о деталях проверки типов,и часто вполне допустимо на стадии анализа и начальных стадиях проектирования полностью забыть овопросах, связанных с типами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
