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

COMPLEX (КОМПЛЕКСНЫЕ) и его наследников CARTESIAN_COMPLEX (КОМПЛЕКСНЫЕ_В_ДЕКАРТОВЫХ_КООРДИНАТАХ) и POLAR_COMPLEX (КОМПЛЕКСНЫЕ_В_ПОЛЯРНЫХ_КООРДИНАТАХ).

Лекция 15. Множественное наследование

Полноценное применение наследования требует важного расширения этого механизма. Изучая его основы, мы столкнулись с необходимостью порождать новые классы от нескольких классов-родителей. Эта возможность, известная как множественное (multiple) наследование (именуемое так в противовес единичному (single) наследованию), действительно нужна для построения надежных ОО-решений.

Примеры множественного наследования

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

[x]. потребность в смене имен компонентов, которая может оказаться полезной и при единичном наследовании;

[x]. дублируемое (repeated) наследование, при котором два класса связаны отношением предок-потомок более чем одним способом.

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

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

Пример, неподходящий для введения

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

В стандартной формулировке примера речь заходит о классах TEACHER и STUDENT, и вам тут же предлагают отметить тот факт, что отдельные студенты тоже преподают, и советуют ввести класс TEACHING_ASSISTANT, порожденный от TEACHER и STUDENT.

Рис. 15.1.  Пример множественного наследования

Выходит, в этой схеме что-то не так? Не обязательно. Но как начальный пример он весьма неудачен. Все дело в том, что STUDENT и TEACHER - не отдельные абстрактные понятия, а вариации на одну тему UNIVERSITY_PERSON. Поэтому, увидев картину в целом, мы обнаружим пример не просто множественного, но дублируемого (repeated) наследования - схемы, изучаемой позже в этой лекции, в которой класс является правильным наследником другого класса двумя или более различными путями:

Рис. 15.2.  А это пример дублируемого наследования

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

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

Может ли самолет быть имуществом?

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

Пусть класс 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