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

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

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

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

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

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

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

Это делает пример с тучей вполне уместным в контексте разработки программ и особенно в проектировании библиотек. Код С++ для логически похожего примера встречается в контексте манипуляторов, используемых для форматированного вывода в библиотеке потоков 621.4.6, з21.4.6.3). Заметьте, что третье решение не является самым «правильным» решением — оно лишь самое универсальное. Проектировщик должен балансировать между множеством различных требований, чтобы выбрать оптимальный уровень общности/абстрактности, подходящий для конкретной проблемы в рамках данной системы. Выскажем грубое эмпирическое соображение, что оптимальным уровнем абстракции для программ длинного цикла жизни является такой, который предоставляет наибольшую универсальность, которую вы только можете себе позволить и воспринять.

Чрезмерная универсальность, выходящая за рамки возможностей индивидуального понимания и технических рамок проекта, причинит один лишь вред: вызовет задержки, приведет к неприемлемо низкой производительности, неуправляемому проекту и, в конце концов, просто к катастрофе. Глава 23. Общий взгляд на разработку программ. Проектирование 824 Чтобы сделать приемы проектирования экономически приемлемыми и управляемыми, мы должны учитывать необходимость повторного использования проекта (э23.5.1) и не забывать совсем уж об эффективности (523.4.7). 23.4.3.

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

Такой набор классов принято называть библиотекой «лассов нли компонентом (с1азз йбга~у нли сотропепг). Иногда все классы компонента составляют единую иерархию классов, иногда — определяются в единственном пространстве имен, а иногда они являются просто произвольным набором объявлений (з24.4). Набор классов объединяется в компонент согласно некоторому логическому критерию, часто по общему стилю, но еще чаще по общему сервису. Таким образом, компонент — это единица проекта, документации и обьект повторного использования. Это не значит, что если применяете один класс из компонента, вы должны понимать код всех остальных классов и использовать их, загружая вхолостую память машины.

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

Итак, рассмотрим, как можно было бы спроектировать компонент. Поскольку часто это непростая задача, разобьем ее на отдельные шаги, чтобы сфокусироваться на отдельных подзадачах логически полным образом. Как обычно, не существует единственного способа сделать такое разбиение. Вот, однако, последовательность шагов, которая помогла многим: 1. Выявите концепции/классы и их фундаментальные взаимосвязи. 2.

Уточните классы, определив набор их операций. ° Классифицируйте эти операции, в том числе определите необходимость конструкторов, деструкторов и операций копирования. ° Обеспечьте минимальное решение, достаточно полное и удобное. 3. Уточните классы в плане их зависимостей. ° Параметризация, наследование и иные типы зависимостей. 4. Определите интерфейсы. ° Разделите функции на открытые и защищенные, ° Определите точный тип операций над классом.

Помните, что это шаги итеративного процесса. Как правило, чтобы получить удобный в работе проект, нужно неоднократно пройтись по этим шагам. Одним из преимуществ качественно выполненного анализа и абстракции данных является относительная простота изменения взаимозависимостей классов даже после того, 23.4. Процесс разработки 825 как написан конкретный код программы. Это, конечно, не совсем тривиальная задача. После этого мы реализуем код классовых методов и пересматриваем проект, учитывая опыт, полученный при реализации кода. В последующих подразделах данной главы мы обсудим все эти шаги последовательно, один за другим. 23.4.3.1. Этап 1: отражение концепций классами Выявите концепции/классы и их фундаментальные взаимосвязи. Ключ к хорошему проекту — это непосредственное моделирование реальностей прикладной задачи в виде классов, представление их взаимосвязей известными способами, например в виде наследования, причем все это нужно периодически повторять на разных уровнях абстракции, Но как на практике нужно выискивать концепции/классы? Как понять, какие именно классы нам нужны? Лучше всего начать такой поиск прямо в самом приложении, а не рыться в портфеле абстракций и концепций компьютерного ученого.

Послушайте того, кто собирается стать профессиональным пользователем вашей системы, или того, кто недоволен существующей системой. Обратите внимание на термины, которыми они при этом оперируют. Часто говорят, что существительные соответствуют классам и объектам программы (и это часто соответствует действительности). Ясно, однако, что это далеко не конец истории. Глаголы соответствуют операциям над объектами, традиционным (глобальным) функциям, возвращающим новые значения на базе их значений-аргументов, и даже классам. Последний случай иллюстрируется классами функциональных объектов (818.4) и манипуляторами (521.4.6).

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

Также важно отойти от близкого соответствия моделям старой программной системы. Например, вряд ли в новой системе нужно подражать старой системе, которая для работы с данными помогала пользователям моделировать «перекладывание бумажек». Иаследование применяется для отражения общности концепций. Что самое важное, наследование должно отражать иерархические отношения классов, моделирующих индивидуальные концепции (81.7, 812.2.б, 824.3.2). Иногда это называют классификацией (с(азз(1)сабоп) или таксономией (гахопоту).

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

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