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