Читать онлайн «Основы объектно-ориентированного программирования». Страница 149

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

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

Пусть класс AIRPLANE описывает самолет. Среди запросов к нему могут быть число пассажиров (passenger_count), высота (altitude), положение (position), скорость (speed); среди команд - взлететь (take_off), приземлиться (land), набрать скорость (set_speed).

Независимо от него может иметься класс ASSET, описывающий понятие имущества. К его компонентам можно отнести такие атрибуты и методы, как цена покупки (purchase_price), цена продажи (resale_value), уменьшить в цене (depreciate), перепродать (resell), внести очередной платеж (pay_installment).

Наверное, вы догадались, к чему мы клоним: компания ведь может владеть самолетом! И для пилота самолет компании это просто машина, способная взлетать, садиться, набирать скорость. Для финансиста это имущество, имеющее (очень высокую) цену покупки, (слишком низкую) цену продажи, и вынуждающее компанию ежемесячно платить по кредиту.

Для моделирования понятия "самолет компании" прибегнем к множественному наследованию:

Рис. 15.3.  Самолет компании

class COMPANY_PLANE inherit

PLANE

ASSET

feature

... Любой компонент, характерный для самолетов компании,

(отличающийся от наследуемых компонентов родителей) ...

end

Родителей класса достаточно перечислить в предложении inherit. (Как обычно, можно разделять их имена точкой с запятой, хотя это не обязательно.) Порядок перечисления классов не играет никакой роли.

В моделировании систем найдется еще немало примеров, подобных COMPANY_PLANE.

[x]. Наручные часы-калькулятор моделируются с применением множественного наследования. Один родитель позволяет устанавливать время и отвечать на такие запросы, как текущее время и текущая дата. Другой - электронный калькулятор - поддерживает арифметические операции.

[x]. Наследником классов судно и грузовик является амфибия (AMPHIBIOUS_VEHICLE). Наследник классов: судно, самолет - гидросамолет (HYDROPLANE). (Как и с TEACHING_ASSISTANT, здесь также возможно дублируемое наследование, поскольку каждый из классов-родителей является потомком средства передвижения VEHICLE.)

[x]. Ужин в ресторане; поездка в вагоне поезда - вагон-ресторан (EATING_CAR). Вариант: спальный вагон (SLEEPING_CAR).

[x]. Диван-кровать (SOFA_BED), на котором можно не только читать, но и спать.

[x]. "Дом на колесах" (MOBILE_HOME) - вид транспорта (VEHICLE) и жилище (HOUSE) одновременно; и так далее.

С точки зрения программиста эти примеры представляют академический интерес - нам платят за построение систем, а не за построение модели мира. Впрочем, во многих практических приложениях с аналогичными комбинациями абстрактных понятий вы обязательно столкнетесь. Более подробный пример из графической среды разработки ISE мы изложим чуть ниже.

Следующий пример напрямую относится к повседневной практике ОО-разработки и неразрывно связан с построением библиотеки Kernel.

Ряд классов Kernel, потенциально необходимых всем приложениям, требуют поддержки таких операций арифметики, как infix "+", infix "-", infix "*", prefix "-", а также специальных значений zero (единичный элемент группы с операцией "+") и one (единичный элемент группы с операцией "*"). Эти компоненты используют отдельные классы библиотеки Kernel: INTEGER, REAL и DOUBLE. Впрочем, они нужны и другим, заранее не определенным классам, например, классу MATRIX, который описывает матрицы определенного вида. Приведенные абстракции уместно объединить в отложенном классе NUMERIC, являющемся частью библиотеки Kernel:

deferred class NUMERIC feature

... infix "+", infix "-", infix "*", prefix "-", zero, one...

end

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

Многим классам необходимо отношение порядка с операциями сравнения элементов. Такая возможность полезна для классов Kernel, таких как STRING, и для многих других классов. Поэтому в состав библиотеки входит отложенный класс COMPARABLE:

deferred class COMPARABLE feature

... infix "<", infix "<=", infix ">", infix ">="...

end

Математически его экземпляры - это полностью упорядоченные множества с заданным отношением порядком.

Не все потомки COMPARABLE должны быть потомками NUMERIC. В классе STRING арифметика не нужна, однако нужен порядок. Обратно, не все потомки NUMERIC должны быть потомками COMPARABLE. Так, на множестве матриц с действительными коэффициентами есть сложение, умножение, единица, нуль, что придает ей свойства кольца, но нет отношения порядка. Поэтому COMPARABLE и NUMERIC должны оставаться различными классами, и ни один из них не должен быть потомком другого.

Объекты некоторых типов, однако, имеют числовую природу и одновременно допускают сравнение. (Такие классы моделируют вполне упорядоченные кольца.) Примеры таких классов - REAL и INTEGER. Целые и действительные числа сравнивают, складывают и умножают. Их описание можно построить на множественном наследовании:

expanded class REAL inherit

NUMERIC

COMPARABLE

feature

...

end

Рис. 15.4.  Структура множественного и единичного наследования

Рассмотрим оконную систему с произвольной глубиной вложения окон:

Рис. 15.5.  Окна и подокна

В соответствующем классе WINDOW мы найдем компоненты двух основных видов:

[x]. те, что рассматривают окно как иерархическую структуру (список подокон, родительское окно, число подокон, добавить, удалить подокно);

[x]. те, что рассматривают окно как графический объект (высота, ширина, отобразить, спрятать, переместить окно).

Этот класс можно написать как единое целое, смешав все компоненты. Однако такой проект будет не самым удачным. Класс WINDOW следует рассматривать как сочетание двух абстракций:

[x]. иерархической структуры, представленной классом TREE;

[x]. прямоугольного экранного объекта, представленного классом RECTANGLE.

На практике класс будет описан так:

class WINDOW inherit

TREE [WINDOW]

RECTANGLE

feature

... Характерные компоненты окна ...

end

Обратите внимание, класс TREE является родовым (generic) классом, а потому требует указания фактического родового параметра, здесь - самого класса WINDOW. Рекурсивная природа определения отражает рекурсию, присущую моделируемой ситуации, - окно является одновременно деревом окон.

Далее, можно подметить, что отдельные окна не содержат ничего, кроме текста. Эту особенность окон можно реализовать вложением, представив класс TEXT_WINDOW как клиента класса STRING, введя атрибут

text: STRING

Предпочтем, однако, вариант, в котором текстовое окно является одновременно строкой. В этом случае используем множественное наследование с родителями WINDOW и STRING. (Если же все наши окна содержат лишь текст, их можно сделать прямыми потомками TREE, RECTANGLE и STRING, однако и здесь решение "в два хода" возможно будет более предпочтительным.)