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

share (other: GIRL) is

-- Выбрать в качестве соседа other.

require

other /= Void

do

roommate := other

end

end

Аналогично следует изменить все порожденные от SKIER классы (закрепление типов мы сейчас не используем). В итоге имеем иерархию:

Рис. 17.5. Иерархия участников и повторные определения

Так как наследование является специализацией, то правила типов требуют, чтобы при переопределении результата компонента, в данном случае roommate , новый тип был потомком исходного. То же касается и переопределения типа аргумента other подпрограммы share . Эта стратегия, как мы знаем, именуется ковариантностью, где приставка "ко" указывает на совместное изменение типов параметра и результата. Противоположная стратегия называется контравариантностью.

Все наши примеры убедительно свидетельствуют о практической необходимости ковариантности.

[x].Элемент односвязного списка LINKABLE должен быть связан с другим подобным себе элементом, а экземпляр BI_LINKABLE - с подобным себе. Ковариантно потребуется переопределяется и аргумент в put_right .

[x].Всякая подпрограмма в составе LINKED_LIST с аргументом типа LINKABLE при переходе к TWO_WAY_LIST потребует аргумента BI_LINKABLE .

[x].Процедура set_alternate принимает DEVICE -аргумент в классе DEVICE и PRINTER -аргумент - в классе PRINTER .

Ковариантное переопределение получило особое распространение потому, что скрытие информации ведет к созданию процедур вида

set_attrib (v: SOME_TYPE) is

-- Установить attrib в v.

...

для работы с attrib типа SOME_TYPE . Подобные процедуры, естественно, ковариантны, поскольку любой класс, который меняет тип атрибута, должен соответственно переопределять и аргумент set_attrib . Хотя представленные примеры укладываются в одну схему, но ковариантность распространена значительно шире. Подумайте, например, о процедуре или функции, выполняющей конкатенацию односвязных списков ( LINKED_LIST ). Ее аргумент должен быть переопределен как двусвязный список ( TWO_ WAY_LIST ). Универсальная операция сложения infix "+"принимает NUMERIC -аргумент в классе NUMERIC , REAL - в классе REAL и INTEGER - в классе INTEGER . В параллельных иерархиях телефонной службы процедуре start в классе PHONE_SERVICE может требоваться аргумент ADDRESS , представляющий адрес абонента, (для выписки счета), в то время как этой же процедуре в классе CORPORATE_SERVICE потребуется аргумент типа CORPORATE_ADDRESS .

Рис. 17.6. Службы связи

Что можно сказать о контравариантном решении? В примере с лыжниками оно означало бы, что если, переходя к классу RANKED_GIRL , тип результата roommate переопределили как RANKED_GIRL , то в силу контравариантности тип аргумента share можно переопределить на тип GIRL или SKIER . Единственный тип, который не допустим при контравариантном решении, - это RANKED_GIRL ! Достаточно, чтобы возбудить наихудшие подозрения у родителей девушек.

Чтобы не оставить камня на камне, рассмотрим вариант примера SKIER с двумя параллельными иерархиями. Это позволит нам смоделировать ситуацию, уже встречавшуюся на практике: TWO_ WAY_LIST > LINKED_LIST и BI_LINKABLE > LINKABLE ; или иерархию с телефонной службой PHONE_SERVICE .

Пусть есть иерархия с классом ROOM , потомком которого является GIRL_ROOM (класс BOY опущен):

Рис. 17.7. Лыжники и комнаты

Наши классы лыжников в этой параллельной иерархии вместо roommate и share будут иметь аналогичные компоненты accommodation ( размещение) и accommodate ( разместить):

indexing

description: "Новый вариант с параллельными иерархиями"

class SKIER1 feature

accommodation: ROOM

accommodate (r: ROOM) is ... require ... do

accommodation:= r

end

end

Здесь также необходимы ковариантные переопределения: в классе GIRL1 как accommodation , так и аргумент подпрограммы accommodate должны быть заменены типом GIRL_ROOM , в классе BOY1 - типом BOY_ROOM и т.д. (Не забудьте: мы по-прежнему работаем без закрепления типов.) Как и в предыдущем варианте примера, контравариантность здесь бесполезна.

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

s: SKIER; b: BOY; g: GIRL

...

create b; create g;-- Создание объектов BOY и GIRL.

s := b; -- Полиморфное присваивание.

s.share (g)

Результат последнего вызова, вполне возможно приятный для юношей, - это именно то, что мы пытались не допустить с помощью переопределения типов. Вызов share ведет к тому, что объект BOY , известный как b и благодаря полиморфизму получивший псевдоним s типа SKIER , становится соседом объекта GIRL , известного под именем g . Однако вызов, хотя и противоречит правилам общежития, является вполне корректным в программном тексте, поскольку share -экспортируемый компонент в составе SKIER , а GIRL , тип аргумента g , совместим со SKIER , типом формального параметра share .

Схема с параллельной иерархией столь же проста: заменим SKIER на SKIER1 , вызов share - на вызов s.accommodate (gr) , где gr - сущность типа GIRL_ROOM . Результат - тот же.

При контравариантном решении этих проблем не возникало бы: специализация цели вызова (в нашем примере s ) требовала бы обобщения аргумента. Контравариантность в результате ведет к более простой математической модели механизма: наследование - переопределение - полиморфизм. Данный факт описан в ряде теоретических статей, предлагающих эту стратегию. Аргументация не слишком убедительна, поскольку, как показывают наши примеры и другие публикации, контравариантность не имеет практического использования.

Поэтому, не пытаясь натянуть контравариантную одежду на ковариантное тело, следует принять ковариантную действительность и искать пути устранения нежелательного эффекта.