Бертран Мейер - Основы объектно-ориентированного программирования

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

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

Рассмотрим структуру, введенную в предыдущей лекции для изучения наследования и содержащую классы графических фигур: FIGURE , OPEN_FIGURE , POLYGON , RECTANGLE , ELLIPSE и т.д. До сих пор в этой структуре использовалось лишь единичное наследование.

Рис. 15.8. Элементарные фигуры

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

Рис. 15.9. Составная фигура

Колесо, в свою очередь, может пригодиться при рисовании велосипеда, и т. д.

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

Назовем новые фигуры составными ( COMPOSITE_FIGURE ). Каждую такую фигуру, безусловно, надо порождать от FIGURE , что позволит ей быть "на равных" с базовыми примитивами. Составная фигура - это еще и список фигур, ее образующих, каждая из которых может быть базовой или составной. Воспользуемся множественным наследованием ( рис. 15.10).

Для получения эффективного класса COMPOSITE_FIGURE выберем одну из возможных реализаций списка, например связный список - LINKED_LIST . Объявление класса будет выглядеть так:

class COMPOSITE_FIGURE inherit

FIGURE

LINKED_LIST [FIGURE]

feature

...

end

Рис. 15.10. Составная фигура - это фигура и список фигур одновременно

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

display is

-- Отображает фигуру, последовательно отображая все ее компоненты.

do

from

start

until

after

loop

item.display

forth

end

end

Я нахожу эту схему прекрасной и, надеюсь, вы тоже пленитесь ее красотой. В ней вы найдете почти весь арсенал средств: классы, множественное наследование, полиморфные структуры данных ( LINKED_LIST [FIGURE] ), динамическое связывание (вызов item.display применяет метод display того класса, которому принадлежит текущий элемент списка), рекурсию (каждый элемент item сам может быть составной фигурой без ограничения глубины вложенности). Подумать только: есть люди, которые могут прожить всю жизнь и не увидеть этого великолепия!

Но можно пойти еще дальше. Обратимся к другим компонентам COMPOSITE_FIGURE - методам вращения ( rotate ) и переноса ( translate ). Они также должны выполнять надлежащие операции над каждым элементом фигуры, и каждый из них может во многом напоминать display . Для ОО-проектировщика это может стать причиной тревоги: хотелось бы избежать повторения; потому выполним преобразование - от инкапсуляции к повторному использованию. (Это могло бы стать девизом.) Техника, рассматриваемая здесь, состоит в использовании отложенного класса "итератор", чьи экземпляры способны выполнять цикл по COMPOSITE_FIGURE . Его эффективным потомком может стать DISPLAY_ ITERATOR , а также ряд других классов. Реализацию этой схемы мы оставляем читателю (см. упражнение 15.4).