Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 173

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

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

Я не утверждаю, что все проектировщики автомобилей так рациональны, как я обрисовал в приведенной аналогии, или что все проектировщики программных продуктов совершают упомянутые ошибки, Напротив, эту модель можно применить для создания программных продуктов. В частности, данная глава и следующая познакомят вас с тем, как данная модель реализуется в С«+. Однако я утверждаю, что из-за неосязаемой природы программ при проектировании программных продуктов избежать по- 769 23А. Процесс разработки добных ошибок труднее (5 24.3А, э 24.3А), а в ~э 23.5.3 я показываю, что от использования приведенной здесь модели людей часто удерживают корпоративные традиции. Отметим, что эта модель разработки хороша в долгосрочной перспективе.

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

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

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

Одна из причин, почему цикл разработки является циклом, в том, что необходимо иметь работающую систему, из которой можно черпать опыт Я 23А.3.6). 23.4.2. Цели проектирования Какие задачи должно решить проектирование? Одна из них, конечно, — достижение простоты, но простоты в каком смысле? Допустим, проект должен развиваться. То есть систему придется расширять, переносить, настраивать, вообще по-разному изменять, и заранее нельзя предвидеть, как именно. Следовательно, мы должны стремиться к проекту и реализации системы, которые имели бы простые средства для внесения в них изменений.

Кроме того, разумно предположить, что со времени первоначального проекта до первой сдачи системы требования к системе несколько раз изменятся. Иэ этого вытекает, что система должна быть спроектирована так, чтобы оставаться как моя<но проще после серии внесенных в нее изменений. Мы должны закладывать изменения в проект; то есть мы должны стремиться к: гибкости; ° способности к расширению; ° переносимости. Лу нпе всего это достигается попытками инкапсулировать те области системы, которые вероятно будут изменяться, и обеспечением такого способа работы, когда последующие проектировщики/программисты вносят изменения в одну область, не затрагивая другие.

Это обеспечивается путем определения для даннои разработки ключевых 770 Глава 23. Разработка и проектирование понятий и придания каждому классу исключительной ответственности за содержание всей информапии, относящейся к отдельному понятию. В этом случае изменение можно внести, модифицировав только один класс. В идеале изменение одного понятия может быть произведено созданием производного класса Я 23А.3,5) или заданием другого аргумента шаблона. Естественно, этот идеал легче провозгласить, чем ему следовать. Рассмотрим пример. В моделировании, связанном с метеорологическими явлениями, мы хотим показать дождевую тучу.

Как нам это сделать? Мы не можем иметь общую процедуру для показа тучи, поскольку ее внешний облик зависит от ее внутреннего состояния, а это состояние должно быть ответственностью только тучи. Первое решение проблемы — дать туче возможность самой показывать себя. Такой стиль решения приемлем во многих конкретных случаях. Однако он не универсален, потому что существует множество способов представления тучи; например, как подробной картины, как грубого силуэта или как условного значка на карте.

Другими словами, то, как выглядит туча, зависит не только от нее самой, но и от окружения. Второе решение проблемы -- сделать так, чтобы туча знала о своем окружении и сама себя отображала. Это решение приемлемо для еще более широкого ряда случаев. Однако это по-прежнему не универсальное решение. Знание тучей всех деталей своего окружения нарушает установку на то, что класс должен отвечать только за одну вещь, и за каждую вещь должен отвечать какой-то один класс. Может оказаться невозможным достичь согласованности в понятии «окружение тучи», потому что, вообще говоря, внешний вид тучи зависит как от нее самой, так и от наблюдателя. Так в реальной жизни, то, как я вижу тучу, сильно зависит от того, как я на нее смотрю: невооруженным глазом, через поляризовшшый фильтр илп с помошью экрана метеорологического радара. Кроме того наблюдателю и туче нужно принимать в расчет «общий фон»вЂ” например, относительное положение солнца.

Еще больше усложняет дело добавление других объектов, таких как соседние тучи и самолеты. Чтобы окончательно усложнить жизнь проектировщику, добавим возможность одновременного присутствия нескольких наблюдателей. Третье решение — заставить тучу (и другие объекты, такие как самолеты и солнце) описывать самих себя для наблюдателя. Это решение достаточно универсально'. Однако, оно может привести к повышению сложности и потере быстродействия.

Например, как нам сделать так, чтобы наблюдатель понял описания, выдаваемые тучами и другими объектами? Дождевые тучи не очень часто встречаются в программах (но для примера ем. э 15.2), однако объекты, которым нужно участвовать во множестве операций вводаувывода, встречаются постоянно.

Это делает тучу значимым примером для программ вообше и проектирования библиотек в частности. Программу на С++ для схожего по логике примера можно найти в манипуляторах, используемых для форматированного потокового ввода/вывода Я 21А.6, Ч 21А.6.3). Отметим, что третье решение не является «правильным», оно просто самое универсальное. Проектировщик должен балансировать между множеством различных потребностей, чтобы выбрать уровень универсальности и абстрагирования, подходяший для данной задачи в данной системе.

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

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

Чрезмерная универсализация, выходягцая за рамки данного проекта н человеческого понимания, может причинить вред; то есть привести к задержкам, неприемлемо низкой эффективности, неуправляемости и просто к ошибкам. Чтобы сделать такие приемы управляемыми и экономичными, мы должны также закладывать в проект возможность повторного использования Я 23.5.1) и не совсем забывать про аффективность Я 23А.7). 23.4.3. Этапы проектирования Рассмотрим проектирование о гдельного класса. Как правило, это не слишком хорошая идея.

Концепции (понятия)нв существуют изолированно; они определяются в контексте дру~ их концепций. Точно также, и класс не существует изолированно, а определяется вместе с логически связанными классами. Как правило, мы работаем с набором взаимосвязанных классов. Такой набор часто называют биолиошекой классов (с1азь 11Ьгагу) или компонентой (сошропепг). Иногда все классы в компоненте составляют иерархщо классов, иногда все онн входя~ в одно пространство имен, а иногда являются просто произвольным набором объявлений Я 24А). Набор классов объединяется в компоненту некоторым логическим критерием, часто благодаря общему стилю, а иногда — нз-за зависимости от одних и тех же услуг.

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

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

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