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

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

rename

foo as fog

redefine

fog

end

...

Если, как и раньше, l: LONDON ; s: SANTA_BARBARA , и выполнено присваивание l := s , то оба вызова l.foo , s.fog включают переопределенную версию компонента fog , объявление которого должно появиться в предложении featureкласса.

Заметьте: redefineсодержит уже новое имя компонента. Это нормально, поскольку под этим именем компонент известен классу. Именно поэтому renameдолжно находиться выше всех остальных предложений наследования (таких, как redefineи пока неизвестные читателю export, undefine, select). После выполнения renameкомпонент теряет свой прежний идентификатор и становится известным под новым именем классу, его потомкам и его клиентам.

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

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

Хорошим примером является класс WINDOW , порожденный от класса TREE . Последний описывает иерархическую структуру, единую для всех деревьев, в том числе и для окон, но имена, понятные в исходном контексте, могут не подходить для интерфейса между WINDOW и его клиентами. Смена имен дает возможность привести их в соответствие с местными обычаями:

class WINDOW inherit

TREE [WINDOW]

rename

child as subwindow, is_leaf as is_terminal, root as screen,

arity as child_count, ...

end

RECTANGLE

feature

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

end

Аналогично, класс TREE , который сам порожден от CELL , может сменить имя right на right_sibling и т.д. Путем смены имен класс может создать удобный набор наименований своих "служб" вне зависимости от истории их создания.