Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 184

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 184)

Но кроме этого, общедоступные основные библиотеки — библиотеки матриц, интерфейсы к базам данных, библиотеки графического интерфейса пользователя и библиотеки поддержки параллелизма — тоже могут сильно влиять на проектные решения. Страх перед новизной часто порождает недостаточное использование средств языка С++.

К этому же приводит неуместный перенос опыта из других предметных областей, сред разработки и языков программирования. Ухудшить проект могут и неадекватные инструменты проектирования. Стоит упомянуть пять ошибок проектирования, которые не позволяют надлежащим образом воспользоваться преимушествами языка и принять во внимание его ограничения: 1.

Отказ от классов — в результате проект приходится выражать с помощью подмножества С++, совпадающего с возможностями языка С. 2. Отказ от производных классов и виртуальных функций — в результате проект использует лишь абстракцию данных. 3. Игнорирование всех возможностей статической проверки типов — в результате программисты вынуждены моделировать динамическую проверку типов. 4. Отказ от самостоятельного этапа программирования — в результате проект приходится подгонять под жесткие рамки, позволяющие обойтись без программистов. 5.

Игнорирование возможностей, альтернативных или дополнительных по отношению к классовым иерархиям. Перечисленные ошибки характерны, соответственно, для проектировщиков, которые: 1. Имеют опыт работы с С, саве-средствами и структурным проектированием. 2. Имеют опыт работы с Аба83, Ч!ьца! Вагйс и активно используют абстракцию данных. 3. Имеют опыт работы со 5ша!П'айг или 1ззр. 4.

Имеют опыт работы в нетехнических или каких-либо иных узкоспециализированных областях. 5. «Зациклились» на «чистом» объектно-ориентированном программировании. 852 Глава 24. Проектирование и программирование В каждом случае следует задуматься, правильно ли выбран язык программирования, правильно ли выбран метод проектирования и не ошибся ли проектировщик в использовании инструментов проектирования. Любое перечисленное несоответствие — это не преступление и его не надо стыдиться. Это просто несоответствие, которое приводит к неоптимальным проектам и лишним проблемам для программистов, которых лучше было бы избежать. Проблемы возникают и у проектировщиков, когда их среда разработки беднее применяемой среды программирования.

По мере возможностей лучше избегать таких несоответствий. Последующие разделы посвящены более подробному анализу перечисленных выше ошибок. 24.2.1. Отказ от классов Рассмотрим вариант проектирования с отказом от классов. Результирующая программа на С++ будет примерно такой же, как программа на С (или на СОВОГО), которая получилась бы в рамках того же самого проекта.

Можно сказать, что в этом случае проект системы «не зависит от языка программирования», так как программисты вынуждены ограничивать себя общим подмножеством С и СОВОЕ. У этого подхода есть свои преимущества. Например, строгое разделение данных и кода упрощает работу с традиционными базами данных, разработанными как раз для таких программ.

Поскольку используется минимальный язык программирования, от программистов требуется минимальная квалификация. Для многих приложений, например тех, что последовательно работают с базами данных, такой образ мыслей вполне оправдан, а разрабатывавшиеся десятилетиями приемы программирования по-прежнему работоспособны.

Естественно, имеются приложения, которые существенно отличаются от программ последовательной работы с записями, например, более сложные интерактивные САБЕ-системы. Отсутствие поддержки абстракции данных, вызванной отказом от применения классов, принесет в таких случаях чистый вред. Внутренняя сложность системы обязательно взыграет где-нибудь в такой программе, а бедность языковых средств не позволит непосредственно отразить в ней элементы проекта. В результате, программа имеет излишне большой размер, плохую проверку типов, и плохо приспособлена к поддержке автоматическими инструментами.

Временным решением проблемы может быть построение некоторых частных инструментов, поддерживающих понятия проектного метода. Эти инструменты возьмут на себя проверку программы на более высоком уровне абстракции, а также проверку типов для компенсации недостаточных возможностей Гнамеренно) обедненного языка реализации. В результате, такой метод проектирования становится специализированным закрытым внутрифирменным языком создания программ. Подобного рода языки программирования в большинстве случаев служат плохой заменой для широко распространенных языков программирования общего назначения, поддержанных подходящими инструментами проектирования. Самая типичная причина отказа от классов — простая инерция.

Традиционные языки программирования не поддерживают понятия класса, так что традиционные методики проектирования вынуждены учитывать это обстоятельство. Главной целью проектирования было разбить задачу на ряд процедур, выполняющих заданные 24 2. Проектирование и язык программирования ВВЗ ограниченные действия. Такой стиль, названный в главе 2 процедурным лрограммирввакием (рюсег(ига1 рюдгатт1лд), в контексте разработки проектов называется функциональной декомпозицыей (гцпсггола1 г(есотршгйов). В связи с этим задают вопрос: «А можно ли применять язык С++ в проектах, основанных на функциональной декомпозиции?».

Можно конечно, но в таком случае вы неизбежно придете к тому, что язык С++ будет использоваться просто как улучшенный С, и столкнетесь с проблемами, рассмотренными выше. Это может быть приемлемо в переходный период, для уже завершенных систем, а также для тех подсистем, где классы, возможно, не принесут больших выгод (с учетом опыта вовлеченных в проект исполнителей). В более долгосрочной перспективе широкомасштабная политика отказа от применения классов, обусловленная применением функциональной декомпозиции, не совместима с эффективным применением С++ и других языков, поддерживающих абстракцию данных.

Процедурно-ориентированный и объектно-ориентированный взгляды на процесс создания программ различаются фундаментально и, как правило, порождают принципиально разные способы решения одной и той же задачи. Это утверждение верно как для этапа проектирования, так и для процесса непосредственного программирования: вы можете сфокусировать проект либо на выполняемых действиях, либо на представляемых сущностях, но не на том и другом одновременно. Так почему же стоит предпочесть объектно-ориентированные методики разработки программ традиционным методам, основанным на функциональной декомпозиции? В первую очередь потому, что функциональная декомпозиция приводит к недостаточной абстракции данных. А отсюда уже следует, что проект будет: ° менее приспособлен к изменениям, ° менее совместим с инструментальными средствами, ° менее приспособлен к параллельной разработке, ° менее удобен для поддержки.

Проблема заключается в том, что функциональная декомпозиция вынуждает делать важные данные глобальными, так как она порождает структуру системы в виде дерева функций, из-за чего данные, с которыми работают несколько функций, должны быть глобальными по отношению к этим функциям. Это приводит к тому, что «интересные» данные всплывают все выше и выше к корню дерева по мере того, как все большее число функций нуждается в доступе к этим данным (считаем, что дерево растет от корня вниз).

Совершенно аналогично, в иерархии классов с одним корнем имеется тенденция поднимать «интересные» данные и функции ближе к корневому (базовому) классу (524.4). Однако когда проект фокусируется на спецификациях классов и инкапсуляции данных, эта проблема решается таким образом, что зависимости между разными частями программы делаются явными и хорошо отслеживаются. Еще важнее то, что при этом вообще ослабляется зависимость разных частей программы друг от друга за счет того, что сильнее локализуются обращения к данным.

Тем не менее, все зависит от конкретных обстоятельств, и некоторые задачи лучше решаются посредством набора процедур. Суть объектно-ориентированного подхода вовсе не в том, чтобы в программе не было глобальных функций и не в том, чтобы в ней вовсе не было процедурно-ориентированных частей, а в том, чтобы программа была разделена на части, каждая из которых наилучшим образом соот- 854 Глава 24. Проектирование и программирование ветствует своей прикладной области.

Чаще всего это достигается в процессе проектирования, ориентированного на классы, а не на глобальные функции. Применять процедурный стиль нужно осознано и обосновано, а не просто так, по умолчанию. И классы, и процедуры должны соответствовать специфике задачи, а не жестко навязанному методу проектирования. 24.2.2. Отказ от производных классов и виртуальных функций Теперь рассмотрим методы проектирования, игнорирующие наследование классов. В этом случае программы просто отказываются использовать одно из самых основных преимуществ С++, хотя и продолжают получать выгоды от С++ по сравнению с С, Рааса!, Роптал, СОВОГО и т.д. Часто в качестве причин такого отказа— кроме инерции — выдвигаются утверждения, что «наследование — это всего лишь деталь реализации», «наследование нарушает сокрытие информации» и что «наследование мешает взаимодействию с другими программами».

Взгляд на наследование как на деталь реализации не учитывает того, что с помощью наследственных иерархий классов можно непосредственно моделировать ключевые взаимоотношения между концепциями и понятиями приложения. Такие взаимоотношения должны также явно прописываться в проекте с тем, чтобы дизайнеры (проектировщики) могли обсуждать их и анализировать. Есть определенные резоны в том, чтобы исключить наследование из частей программы, взаимодействующих с кодом, написанным на других языках программирования. Это, однако, не является достаточным обоснованием для полного отказа от наследования в иных частях программы. Нужно всего лишь более тщательно определить и изолировать интерфейс взаимодействия с «внешним миром».

Аналогично, беспокойства о нарушении сокрытия информации посредством использования наследования (824.3.2.1) являются причиной для более тщательного проектирования виртуальных функций и защищенных членов (815.3). Это не причина отказываться от наследования вообще.

Характеристики

Список файлов книги