Множественное наследование

Примеры множественного наследования
Выясним, прежде всего, в каких ситуациях множественное наследование и в самом деле уместно. Для этого рассмотрим ряд типичных примеров, заимствованных из разных предметных областей.
Такой краткий экскурс тем более необходим, что несмотря на элегантность, простоту множественного наследования и реальную потребность в нем, демонстрация этого механизма подчас создает впечатление чего-то сложного и таинственного. И хотя эту точка зрения не подтверждает ни практика, ни теория, она распространилась достаточно широко, и теперь мы просто обязаны потратить немного времени на изучение случаев, в которых множественное наследование действительно совершенно необходимо.
Пример, неподходящий для введения
Сначала покончим с одним бытующим заблуждением. Для этого рассмотрим пример, приводимый (в том или ином виде) во многих статьях, книгах и лекциях, но зачастую порождающий недоверие к множественному наследованию. И дело не в том, что этот пример неверен; просто при первом знакомстве с проблемой он не может служить иллюстрацией, поскольку являет собой образец нетипичного применения этого механизма.
В стандартной формулировке примера речь заходит о классах TEACHER и STUDENT, и вам тут же предлагают отметить тот факт, что отдельные студенты тоже преподают, и советуют ввести класс TEACHING_ASSISTANT, порожденный от TEACHER и STUDENT.
Выходит, в этой схеме что-то не так? Не обязательно. Но как начальный пример он весьма неудачен. Все дело в том, что STUDENT и TEACHER - не отдельные абстрактные понятия, а вариации на одну тему UNIVERSITY_PERSON. Поэтому, увидев картину в целом, мы обнаружим пример не просто множественного, но дублируемого (repeated) наследования - схемы, изучаемой позже в этой лекции, в которой класс является правильным наследником другого класса двумя или более различными путями:
Дублируемое наследование - это особый случай. Его применение требует большого опыта в использовании более простых форм порождения классов. Этот пример нельзя обсуждать с начинающими просто потому, что он создает впечатление конфликтов между отдельными компонентами, наследуемых от обоих родителей, в то время как речь идет о свойстве, приходящем от общего предка. При правильном подходе исправить эту проблему не составит труда. Но было бы серьезной ошибкой начинать разговор с таких исключительных и непростых случаев, делая вид, будто они характерны для всего множественного наследования.
По-настоящему распространенные случаи множественного наследования не вызывают таких проблем. В их основе - не варианты одной, а сочетание различных абстракций. Именно это чаще всего и требуется при построении структур наследования, именно это и следует обсуждать при первом знакомстве с предметом. Дальнейшие примеры - из этой серии.
Может ли самолет быть имуществом?
Наш первый подходящий пример относится скорее к моделированию систем, чем к проектированию программных продуктов. Однако он наглядно иллюстрирует ситуацию, в которой множественное наследование необходимо.
Пусть класс AIRPLANE описывает самолет. Среди запросов к нему могут быть число пассажиров (passenger_count), высота (altitude), положение (position), скорость (speed); среди команд - взлететь (take_off), приземлиться (land), набрать скорость (set_speed).
Независимо от него может иметься класс ASSET, описывающий понятие имущества. К его компонентам можно отнести такие атрибуты и методы, как цена покупки (purchase_price), цена продажи (resale_value), уменьшить в цене (depreciate), перепродать (resell), внести очередной платеж (pay_installment).
Наверное, вы догадались, к чему мы клоним: компания ведь может владеть самолетом! И для пилота самолет компании это просто машина, способная взлетать, садиться, набирать скорость. Для финансиста это имущество, имеющее (очень высокую) цену покупки, (слишком низкую) цену продажи, и вынуждающее компанию ежемесячно платить по кредиту.
Для моделирования понятия "самолет компании" прибегнем к множественному наследованию:
class COMPANY_PLANE inherit
PLANE
ASSET
feature
... Любой компонент, характерный для самолетов компании,
(отличающийся от наследуемых компонентов родителей) ...
end

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

• Наручные часы-калькулятор моделируются с применением множественного наследования. Один родитель позволяет устанавливать время и отвечать на такие запросы, как текущее время и текущая дата. Другой - электронный калькулятор - поддерживает арифметические операции.
• Наследником классов судно и грузовик является амфибия (AMPHIBIOUS_VEHICLE). Наследник классов: судно, самолет - гидросамолет (HYDROPLANE). (Как и с TEACHING_ASSISTANT, здесь также возможно дублируемое наследование, поскольку каждый из классов-родителей является потомком средства передвижения VEHICLE.)
• Ужин в ресторане; поездка в вагоне поезда - вагон-ресторан (EATING_CAR). Вариант: спальный вагон (SLEEPING_CAR).
• Диван-кровать (SOFA_BED), на котором можно не только читать, но и спать.
• "Дом на колесах" (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

Окна - это деревья и прямоугольники
Рассмотрим оконную систему с произвольной глубиной вложения окон:
В соответствующем классе WINDOW мы найдем компоненты двух основных видов:

• те, что рассматривают окно как иерархическую структуру (список подокон, родительское окно, число подокон, добавить, удалить подокно);
• те, что рассматривают окно как графический объект (высота, ширина, отобразить, спрятать, переместить окно).

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

• иерархической структуры, представленной классом TREE;
• прямоугольного экранного объекта, представленного классом RECTANGLE.

На практике класс будет описан так:
class WINDOW inherit
TREE [WINDOW]
RECTANGLE
feature
... Характерные компоненты окна ...
end

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

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

Деревья - это списки и их элементы

Класс дерева TREE - еще один яркий пример множественного наследования.
Деревом называется иерархическая структура, составленная из узлов с данными. Обычно ее определяют так: "Дерево либо пусто, либо содержит объект, именуемый его корнем, с присоединенным списком деревьев (рекурсивно определяемых) - потомков корневого узла". К этому добавляют определение узла: "Пустое дерево не содержит узлов; узлами непустого дерева являются его корень и по рекурсии узлы потомков". Эти определения, хотя и отражают рекурсивную сущность дерева, не способны показать его внутренней простоты.
Мы же заметим, что между понятиями дерева и узла нет серьезных различий. Узел можно определить как поддерево, корнем которого он является. В итоге приходим к классу TREE [G], который описывает как узлы, так и деревья. Формальный родовой параметр G отражает тип данных в каждом узле. Следующее дерево, является, например, экземпляром TREE [INTEGER]:
Вспомним также о понятии списка, чей класс LIST рассмотрен в предыдущих лекциях. В общем случае его реализация требует введения класса CELL для представления его элементов структуры.
Эти понятия позволяют прийти к простому определению дерева: дерево (или его узел) есть список, - список его потомков, но является также потенциальным элементом списка, поскольку может представлять поддерево другого дерева.
Определение: дерево
Дерево - это список и элемент списка одновременно.
Это определение еще потребует доработки, однако, уже сейчас позволяет описать класс:
deferred class TREE [G] inherit
LIST [G]
CELL [G]
feature
...
end

От класса LIST наследуются такие компоненты как количество узлов (count), добавление, удаление узлов и т. д.
От класса CELL наследуются компоненты, позволяющие работать с узлами, задающими родителя или братьев: следующий брат, добавить брата, присоединить к другому родителю.
Этот пример характерен тем, что иллюстрирует преимущества повторного использования при множественном наследовании. Создание специальных компонентов вставки или удаления поддеревьев означало бы повторение того, что уже сделано для списка элементов. Нам же остаются лишь косметические доработки.
Кроме того, следует позаботиться о добавлении в предложение feature специфических компонентов, присущих только деревьям, и компонентов, являющихся результатом взаимных компромиссов, неизбежных при любой свадьбе, и обеспечивающих взаимную гармонию родительских классов. Их текст невелик и займет в классе TREE чуть больше страницы, поскольку наш класс вполне законный плод союза списков и элементов списка.

Составные фигуры
Следующий пример больше чем пример, - он послужит нам образцом проектирования классов в самых различных ситуациях.
Рассмотрим структуру, введенную в предыдущей лекции для изучения наследования и содержащую классы графических фигур: FIGURE, OPEN_FIGURE, POLYGON, RECTANGLE, ELLIPSE и т.д. До сих пор в этой структуре использовалось лишь единичное наследование.
Пусть в этой иерархии представлены все нужные нам базовые фигуры. Однако в библиотеку классов хотелось бы включить и не базовые фигуры, имеющие широкое распространение. Конечно, любое изображение каждый раз можно строить из примитивов, но это неудобно. Поэтому мы создадим библиотеку фигур, часть которых будут базовыми, а часть - построена на их основе. Так, из экземпляров базисных классов: отрезка и окружности можно собрать колесо:
Колесо, в свою очередь, может пригодиться при рисовании велосипеда, и т. д.
Итак, нам необходим универсальный механизм создания новых фигур, построенных на основе существующих, но, будучи построенными, используемыми наравне с базовыми.
Назовем новые фигуры составными (COMPOSITE_FIGURE). Каждую такую фигуру, безусловно, надо порождать от FIGURE, что позволит ей быть "на равных" с базовыми примитивами. Составная фигура - это еще и список фигур, ее образующих, каждая из которых может быть базовой или составной. Воспользуемся множественным наследованием .
Для получения эффективного класса COMPOSITE_FIGURE выберем одну из возможных реализаций списка, например связный список - LINKED_LIST. Объявление класса будет выглядеть так:
class COMPOSITE_FIGURE inherit
FIGURE
LINKED_LIST [FIGURE]
feature
...
end

Предложение 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).
Описание составных структур с применением множественного наследования и списка или иного контейнерного класса, как одного из родителей, - это универсальный образец проектирования. Примерами его воплощения являются подменю (см. упражнение 15.8), а также составные команды в ряде интерактивных систем.
Брак по расчету
В приведенных примерах оба родителя играли симметричные роли, но это не всегда так. Иногда вклад каждого из них различен по своей природе.
Важным приложением множественного наследования является обеспечение реализации абстракции, описанной отложенным классом, используя свойства, обеспечиваемые эффективным классом. Один класс абстрактен, второй - эффективен.
Рассмотрим реализацию стека, заданную массивом. У нас уже есть классы для поддержки стеков и массивов в отдельности (абстрактный STACK и эффективный ARRAY, см. предыдущие лекции). Лучший способ реализации класса ARRAYED_STACK (стек, заданный массивом) - описать его как наследника классов STACK и ARRAY. Это концептуально верно: стек-массив одновременно является стеком (с точки зрения клиента) и массивом (с позиций поставщика). Вот описание класса:
indexing
description: "Стек, реализованный массивом"
class ARRAYED_STACK [G] inherit
STACK [G]
ARRAY [G]
... Здесь будут добавлены предложения переименования ...
feature
...Реализация отложенных подпрограмм класса STACK
в терминах операций класса ARRAY (см. ниже)...
end

ARRAYED_STACK предлагает ту же функциональность, что и STACK, делая эффективными отложенные компоненты: full, put, count ..., реализуя их как операции над массивом.
Вот схема некоторых типичных компонентов: full, count и put. Так, условие, при котором стек полон, имеет вид:
full: BOOLEAN is
-- Является ли стек (его представление) заполненным?
do
Result := (count = capacity)
end

Компонент capacity унаследован от класса ARRAY и задает емкость стека, равную числу элементов массива. Для count потребуется ввести атрибут:
count: INTEGER

Это пример эффективной реализации отложенного компонента как атрибута. Наконец,
put (x: G) is
-- Втолкнуть x на вершину.
require
not full
do
count := count + 1
array_put (x, count)
end

Процедура array_put унаследована от класса ARRAY. Ее цель - записать новое значение в указанный элемент массива.

Класс ARRAYED_STACK типичен как вариант наследования, образно именуемый "брак по расчету". Оба класса, - абстрактный и эффективный, - дополняя друг друга, создают достойную пару.
Помимо эффективной реализации методов, отложенных (deferred) в классе STACK, класс ARRAYED_STACK способен переопределять реализованные. Компонент change_top, реализованный в STACK в виде последовательности вызовов remove и put, можно переписать более эффективно:
array_put (x, count)

Указание на переопределение компонента следует ввести в предложение наследования:
class ARRAYED_STACK [G] inherit
STACK [G]
redefine change_top end
... Остальное, как прежде ...

Инвариант этого класса может иметь вид
invariant
non_negative_count: count >= 0
bounded: count <= capacity

Первое утверждение выражает свойство АТД. Фактически оно присутствует в родительском классе STACK и потому является избыточным. Здесь оно приводится в педагогических целях. Из окончательной версии класса его нужно изъять. Второе утверждение включает емкость массива - capacity. Это - инвариант реализации.
Сравнив ARRAYED_STACK с представленным ранее классом STACK2, вы увидите, как сильно он упростился благодаря наследованию. Это сравнение мы продолжим при обсуждении методологии наследования, в ходе которого ответим на критику, звучащую иногда в адрес наследования "по расчету" и так называемого наследования реализаций.
Структурное наследование
Множественное наследование просто необходимо, когда необходимо задать для класса ряд дополнительных свойств, помимо свойств, заданных базовой абстракцией.
Рассмотрим механизм создания объектов с постоянной структурой (способных сохраняться на долговременных носителях). Поскольку объект является "сохраняемым", то у него должны быть свойства, позволяющие его чтение и запись. В библиотеке Kernel за эти свойства отвечает класс STORABLE, который может быть родителем любого класса. Очевидно, такой класс, помимо STORABLE, должен иметь и других родителей, а значит, схема не сможет работать, не будь множественного наследования. Примером может служить изученное выше наследование с родителями COMPARABLE и NUMERIC. Форма наследования при которой родитель задает общее структурное свойство, и, чаще всего, имеет имя, заканчивающееся на - ABLE, называется схемой наследования структурного вида.
Без множественного наследования нет способа указать, что некоторая абстракция обладает двумя структурными свойствами - числовыми и сохранения, сравнения и хеширования. Выбор только одного из родителей подобен выбору между отцом и матерью.
Наследование функциональных возможностей
Вот еще одна типичная ситуация. Многие программные инструменты должны сохранять "историю", что позволяет пользователям:

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

Такой механизм привлекателен для любой интерактивной среды, однако его создание требует больших усилий. Поэтому историю поддерживают лишь немногие инструменты (к примеру, ряд "командных оболочек" Unix и Windows), да и те нередко частично. Универсальные же решения не зависят от конкретного инструмента. Их можно инкапсулировать в класс, а от него - породить другой класс для управления рабочей сессией любого инструмента. (Решение с применением классов-клиентов допустимо, но не так привлекательно.) И снова без множественного наследования не обойтись, так как недостаточно иметь родителя, знающего только историю.
Набор полезных возможностей предоставляет класс TEST, инкапсулирующий ряд механизмов тестирования класса: прием и хранение данных от пользователя, вывод и хранение результата, сравнение, регрессное тестирование и т.д. Хотя решение с использованием вложения может быть предпочтительным, неплохо иметь возможность при тестировании класса X определять класс X_TEST, порожденный от X и TEST.
Далее мы будем встречать и другие примеры наследования функциональных возможностей, при котором один класс F инкапсулирует набор, например констант или методов математической библиотеки, а другой, объявляя себя потомком F, может ими воспользоваться.
Лунка и кнопка
Вот пример, в котором, как и раньше, без множественного наследования не обойтись. Идейно он близок к примеру с корпоративным самолетом, спальным вагоном и другими типами, полученными в результате объединения абстракций. Впрочем, теперь мы будем работать с понятиями из практики программирования.
Среда разработки ISE, описанная вкурса "Основы объектно-ориентированного проектирования", подобно другим графическим приложениям, содержит "кнопки" для выполнения определенных действий. В среду встроен механизм "выбрать и перетащить" (pick and throw), аналог традиционного механизма буксировки drag-and-drop. С его помощью можно выбрать объект на экране; при этом курсор мыши превращается в "камешек", форма которого указывает тип выбранного объекта. Камешек можно перетащить и опустить в лунку, форма которой соответствует камешку, инициируя тем самым определенное действие. Например, инструментарий Class Tool, позволяющий исследовать свойства класса, имеет "классную лунку", опустив в которую камешек нового класса, вы перенастроите инструмент на показ его свойств.
Обратите внимание на нижнюю строку с кнопками форматирования. Нажатие каждой из них позволяет получить разнообразную информацию о классе ARRAY, например краткую форму класса. Как показано на рисунке, пользователь, работая в окне Feature Tool, выбрал щелчком правой кнопки класс INTEGER. Он передвигает его в направлении "лунки" класса в окне Class Tool, настроенного сейчас на ARRAY. Перетаскивание завершается щелчком правой кнопки на "лунке" класса, форма которой соответствует форме камешка. Тем самым Class Tool будет перенастроен на работу с выбранным классом INTEGER.
Иногда удобнее, чтобы "лунка" была одновременно и кнопкой, что позволяет не только "загонять" в нее объект, но независимо от этого щелкать по ней левой кнопкой. Таковой является наша "лунка" класса, точка внутри которой указывает на присутствие в ней объекта (сначала ARRAY, а затем INTEGER). Щелчок по ней левой кнопкой перенастроит инструмент на работу с текущим объектом, что полезно, когда дисплей отражает другую информацию. Такая лунка с кнопкой реализуется специальным классом BUTTONHOLE.
Нетрудно догадаться, что класс BUTTONHOLE возникает в результате наследования от классов BUTTON и HOLE. Новый класс сочетает в себе компоненты и свойства обоих родителей, реагирует как кнопка, и допускает операции как над лункой.
Оценка
Приведенные примеры наглядно проиллюстрировали мощь и силу механизма множественного наследования. Необходимость его применения подтверждена опытом построения универсальных библиотек [M 1994a].
Как объединить две абстракции, если множественное наследование недоступно? Видимо, вы должны выбрать одну из них как "официальный" родительский класс, а все компоненты второй просто скопировать, превратив новый класс в ее "нелегального" потомка. В результате на нелегальной части класса теряется полиморфизм, все преимущества повторного использования и многое другое, что неприемлемо.

Переименование компонентов

Иногда при множественном наследовании возникает проблема конфликта имен (name clash). Ее решение - переименование компонентов (feature renaming) - не только снимает саму проблему, но и способствует лучшему пониманию природы классов.
Конфликт имен
Каждый класс обладает доступом ко всем компонентам своих родителей. Он может использовать их, не указывая тот класс, в котором они были описаны. После обработки inherit в классе class C inherit A ... метод f класса C становится известен как f. То же справедливо и для клиентов: при объявлении сущности x типа C вызов компонента записывается как x.f без каких-либо ссылок на A. Все метафоры "хромают", иначе можно было бы говорить, что наследование - форма усыновления: C усыновляет все компоненты A.
Усыновление не меняет присвоенных имен, и набор имен компонентов данного класса содержит наборы имен компонентов каждого его родителя.
А если родители класса разные компоненты назвали одним именем? Возникает противоречие, поскольку согласно установленному ранее правилу запрещена перегрузка имен: в классе имя компонента обозначает только один компонент. Это правило не должно нарушаться при наличии родителей класса. Рассмотрим пример:
class SANTA_BARBARA inherit
LONDON
NEW_YORK
feature
...
end-- class SANTA_BARBARA

Что предпринять, если LONDON и NEW_YORK имеют в своем составе компонент с именем, например, foo (нечто)?
Ни при каких обстоятельствах нельзя нарушить запрет перегрузки имен компонентов. Как следствие, класс SANTA_ BARBARA окажется некорректным, что обнаружится при трансляции.

Что делать? Исходный код классов LONDON и NEW_YORK может быть недоступен; или на его исправления может быть наложен запрет; а при отсутствии такого запрета, возможно, вам не захочется ничего менять, поскольку LONDON написан не вами, и выход новой версии класса заставит все начинать с нуля. Наконец, самое главное, принцип Открыт-Закрыт не разрешает исправлять модули при их повторном использовании.
Всегда ошибочно обвинять в грехах своих родителей. Проблема конфликта имен возникла в самом классе. В нем должно найтись и решение.
Класс, наследующий от разных родителей разные компоненты с идентичным именем, не будет корректен, пока мы не включим в его декларацию наследования одно или несколько предложений переименования rename. Каждое из них назначает новое локальное имя одному или нескольким унаследованным компонентам. Например:
class SANTA_BARBARA inherit
LONDON
rename foo as fog end
NEW_YORK
feature
...
end

Как внутри SANTA_BARBARA, так и во всех клиентах этого класса компонент LONDON с именем foo будет именоваться fog, а одноименный компонент NEW_YORK - просто foo. Клиенты LONDON, как и прежде, будут знать этот компонент под именем foo.
Этого достаточно для устранения конфликта (если других совпадений нет, а класс LONDON и класс NEW_YORK не содержат компонента с именем fog). В противном случае можно переименовать компонент класса NEW_YORK:
class SANTA_BARBARA inherit
LONDON
rename foo as fog end
NEW_YORK
rename foo as zoo end
feature
...
end

Предложение rename следует за указанием имени родителя и предшествует любым выражениям redefine, если таковые имеются. Можно переименовать и несколько компонентов, как в случае:
class TREE [G] inherit
CELL [G]
rename item as node_item, put as put_right end

где устраняется конфликт между одноименными компонентами CELL и LIST. Компоненту CELL с именем item дается идентификатор node_item, аналогично и put переименовывается в put_right.
Результат переименования
Убедимся, что нам понятен результат этого действия. Пусть класс SANTA_BARBARA имеет вид (оба унаследованных компонента foo в нем переименованы):
 (Обратите внимание на графическое обозначение операции смены имен.) Пусть также имеются сущности трех видов:
l: LONDON; n: NEW_YORK; s: SANTA_BARBARA

Вызовы l.foo и s.fog будут являться корректными. После полиморфного присваивания l := s все останется корректным, поскольку имена обозначают один и тот же компонент. Аналогично, корректны вызовы n.foo, s.zoo, которые после n := s также будут давать одинаковый результат.
В то же время, следующие вызовы некорректны:

• l.zoo, l.fog, n.zoo, n.fog, так как ни LONDON, ни NEW_YORK не содержат компонентов с именем fog или zoo;
• s.foo, поскольку после смены имен класс SANTA_BARBARA уже не имеет компонента с именем foo.

При всей искусственности имен пример хорошо иллюстрирует природу конфликта имен. Хотите верьте, хотите нет, но приходилось слышать, что конфликт порождает "глубокую семантическую проблему". Это неправда. Конфликт имен - простая синтаксическая проблема. Если бы автор первого класса сменил имя компонента на fog, или автор второго - на zoo, конфликта бы не было, и в каждом случае - это всего лишь замена буквы. Конфликт имен - это обычная неудача, он не вскрывает никаких глубоких проблем, связанных с классами, и не свидетельствует об их неспособности работать совместно. Возвращаясь к метафоре брака, можно сказать, что конфликт имен - это не драма (обнаруженная несовместимость групп крови), а забавный факт (матери обоих супругов носят имя Татьяна, и это вызовет трудности для будущих внуков, которые можно преодолеть, договорившись, как называть обеих бабушек).