Объектно-ориентированный анализ и проектирование с примерами приложений на С++

 ∙ Список   Последовательность элементов, имеющая начало; структурное разделение допускается. 

 ∙ Стек   Последовательность элементов; элементы могут удаляться и добавляться только с одного конца. 

 ∙ Очередь   Последовательность элементов, к которой можно добавлять элементы с одного конца, а удалять - с другого. 

 ∙ Дека   Последовательность элементов, к которой можно добавлять и из которой можно удалять элементы с обоих концов. 

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

 ∙ Строка   Индексируемая последовательность элементов, в которой возможны операции с подстроками. 

 ∙ Ассоциативный массив   Словарь пар "элемент/значение". 

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

 ∙ Граф   Множество вершин и ребер (без выделенного начального элемента), которое может содержать циклы и пересечения; структурное разделение допускается. 

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

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

Для некоторых классов в процессе анализа выявилась желательность их функциональной изменчивости. В частности, нам могут понадобиться упорядоченные коллекции, деки и очереди (последние часто называют приоритетными очередями). Кроме того, мы можем различать ориентированные и неориентированные графы, односвязные и двусвязные списки, бинарные, множественные и AVL-деревья [AVL-дерево - предложенная Г.М.Адельсон-Вольским и Е.М.Ландисом конструкция подравниваемого бинарного дерева. - Примеч. ред.]. Эти специализированные абстракции могут быть получены уточнением одной из вышеперечисленных; их не следует выделять в отдельные большие категории.

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

Мы выделим следующие типы инструментов:  

∙ Дата/Время   Операции с датой и временем. 

 ∙ Фильтры   Ввод, обработка и вывод. 

 ∙ Поиск по образцу   Операции поиска последовательностей внутри других последовательностей. 

 ∙ Поиск   Операции поиска элементов внутри структур. 

 ∙ Сортировка   Операции упорядочивания структур. 

 ∙ Утилиты   Составные операции, базирующиеся на базовых структурных операциях. 

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

Модели взаимодействий

Итак, мы определили основные функциональные элементы нашей библиотеки; однако изолированные абстракции сами по себе - еще не среда разработки. Как отметил Вирфс-Брок: "Среда разработки предоставляет пользователю модель взаимодействий между объектами входящих в нее классов... Чтобы освоить среду разработки, прежде всего следует изучить методы взаимодействия и ответственности ее классов". Это и есть тот критерий, по которому можно отличить среду разработки от простого набора классов: среда - это совокупность классов и механизмов взаимодействия экземпляров этих классов.

Анализ показывает, что существует определенный набор основных механизмов, необходимый для библиотеки базовых классов:

• семантика времени и памяти;

• управление хранением данных;

• обработка исключений;

• идиомы итерации;

• синхронизация при многопоточности.

При проектировании системы базовых классов необходимо сохранять баланс между перечисленными техническими требованиями [Действительно, как отмечает Страуструп, "разработка универсальной библиотеки значительно сложнее, чем разработка отдельной программы" [10]]. Если мы будем пытаться решить каждую задачу по отдельности, то, скорее всего, получим ряд изолированных решений, не связанных между собой ни общими протоколами, ни общей концепцией, ни реализацией. Такой наивный подход приведет к изобилию различных подходов, которое испугает потенциального пользователя получившейся библиотеки.