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

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 в нем переименованы):

Рис. 15.13. Устранение конфликта имен

(Обратите внимание на графическое обозначение операции смены имен.) Пусть также имеются сущности трех видов:

l: LONDON; n: NEW_YORK; s: SANTA_BARBARA

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

В то же время, следующие вызовы некорректны:

[x]. l.zoo , l.fog , n.zoo , n.fog , так как ни LONDON , ни NEW_YORK не содержат компонентов с именем fog или zoo ;

[x]. s.foo , поскольку после смены имен класс SANTA_BARBARA уже не имеет компонента с именем foo .

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

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

[x].Переопределение меняет компонент, но сохраняет его имя.

[x].Переименование меняет имя, но сохраняет компонент.

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

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

Иногда то и другое можно совмещать:

class SANTA_BARBARA inherit

LONDON