30. Стандартные контейнеры. Вопросы производительности операций.

Стандартные контейнеры

Контейнер	Операция []	Операции со списками	Операции с началом	Операции с концом	Итераторы
Vector	Const	O(n)	-	Const+	Random
List	-	Const	Const	const	Bi
Deque	Const	O(n)	Const	Const	Random
Stack	-	O(n)	-	Const	-
Queue	-	O(n)	Const	Const	-
Priority_queue	-	O(ln(n))	O(ln(n))	O(ln(n))	-
Map	O(ln(n))	O(ln(n))	-	-	Bi
Multimap	-	O(ln(n))	-	-	Bi
Set	O(ln(n))	O(ln(n))	-	-	Bi
Multiset	-	O(ln(n))	-	-	Bi
String	Const	O(n)	O(n)	Const+	Random
Array	Const	-	-	-	Random
Valarray	Const	-	-	-	Random
Bitset	Const	-	-	-	-

31. Процесс разработки по. Цели и этапы проектирования.

Каковы задачи, стоящие перед проектированием? Безусловно достижение про­стоты, но простоты в каком смысле, ведь проект должен развиваться? Он будет рас­ширяться, портироваться, настраиваться и вообще меняться столь большим числом способов, что их невозможно предвидеть. Следовательно, мы должны стремиться к тому, чтобы в проект системы и ее реализацию было легко вносить изменения. Нет ничего удивительно в том, что требования к системе и изменения в проект бу­дут несколько раз вноситься даже при разработке самого первого выпуска продукта.

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

• гибкости,

• расширяемости,

• переносимости.

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

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

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

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

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

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

Тучи не являются частыми гостями программных проектов (для примера см. §15.2), но вот другие объекты, которые вовлекаются во множество операций вво­да/вывода, встречаются часто. Это делает пример с тучей вполне уместным в кон­тексте разработки программ и особенно в проектировании библиотек. Код C++ для логически похожего примера встречается в контексте манипуляторов, исполь­зуемых для форматированного вывода в библиотеке потоков (§21.4.6, §21.4.6.3). Заметьте, что третье решение не является самым «правильным» решением — оно лишь самое универсальное. Проектировщик должен балансировать между множе­ством различных требований, чтобы выбрать оптимальный уровень общности/аб­страктности, подходящий для конкретной проблемы в рамках данной системы. Выскажем грубое эмпирическое соображение, что оптимальным уровнем абстрак­ции для программ длинного цикла жизни является такой, который предоставляет наибольшую универсальность, которую вы только можете себе позволить и вос­принять. Чрезмерная универсальность, выходящая за рамки возможностей инди­видуального понимания и технических рамок проекта, причинит один лишь вред: вызовет задержки, приведет к неприемлемо низкой производительности, не­управляемому проекту и, в конце концов, просто к катастрофе.

Чтобы сделать приемы проектирования экономически приемлемыми и управ­ляемыми, мы должны учитывать необходимость повторного использования проек­та (§23.5.1) и не забывать совсем уж об эффективности (§23.4.7).

Этапы проектирования

Рассмотрим проектирование отдельного класса. В общем случае, это не слиш­ком хорошая идея. Концепции не существуют в полной изоляции; скорее, концепции определяются в контексте других концепций. Точно так же, и классы не существу­ют изолированно. Они определяются совместно с логически связанными с ними классами. Как правило, мы работаем с набором логически связанных классов. Та­кой набор классов принято называть библиотекой классов или компонентом (class library или component). Иногда все классы компонента составляют единую иерархию классов, иногда — определяются в единственном пространстве имен, а иногда они являются просто произвольным набором объявлений (§24.4).

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

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

1. Выявите концепции/классы и их фундаментальные взаимосвязи.

2. Уточните классы, определив набор их операций.

• Классифицируйте эти операции, в том числе определите необходимость конструкторов, деструкторов и операций копирования.

• Обеспечьте минимальное решение, достаточно полное и удобное.

3. Уточните классы в плане их зависимостей.

• Параметризация, наследование и иные типы зависимостей.

4. Определите интерфейсы.

• Разделите функции на открытые и защищенные.

• Определите точный тип операций над классом.

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

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