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

if "f типа RECTANGLE" then

...

elseif "f типа CIRCLE" then

...

и т.д.

Это решение идет вразрез с принципами Единственного Выбора и Открыт-Закрыт. Избежать риска потерь нам помогут два обстоятельства.

[x].Нет смысла создавать универсальный механизм выяснения типа объектов. В том и другом случае тип объекта предположительно известен. Все, что нам нужно, - это способ проверки гипотезы. Определение принадлежности объекта данному типу носит более частный характер, чем запрос на определение типа. Кроме того, нам нетребуется вводить в наш язык никаких операций над типами, к примеру, их сравнение - ужасающая мысль.

[x].Как уже говорилось, мы не должны влиять на правило Вызова Компонентов. Ни при каких обстоятельствах мы не должны проверять применимость вызова компонента, если класс прошел статистическую проверку. Все, что нам нужно, - это более свободная версия другого правила - правила совместимости типов, позволяющая "испытать тип" и проверить результат.

И снова запись механизма решения напрямую вытекает из анализа поставленной проблемы. Введем новую форму присваивания, назвав ее попыткой присваивания (assignment attempt):

target ?= source

Знак вопроса указывает на предварительный характер операции. Пусть сущность target имеет тип T , тогда попытка присваивания дает следующий результат:

[x].если source ссылается на объект совместимого с T типа, присоединить target к объекту так, как это делает обычное присваивание;

[x].иначе (если source равно void или ссылается на объект несовместимого типа) приписать target значение void .

На эту инструкцию не действуют никакие ограничения типов, кроме одного: тип target (T) должен быть ссылочным.

Новое средство быстро и элегантно решает поставленные проблемы и, прежде всего, дает возможность обращаться к объектам полиморфной структуры с учетом их типа:

maxdiag (figlist: LIST [FIGURE]): REAL is

-- Максимальная длина диагонали прямоугольника в списке;

-- если прямоугольников нет, то -1.

require

list_exists: figlist /= Void

local

r: RECTANGLE

do

from

figlist.start; Result := -1.0

until

figlist.after

loop

r ?= figlist.item

if r /= Void then

Result := Result.max (r.diagonal)

end

figlist.forth

end

end

Здесь применяются обычные итерационные механизмы работы с последовательными структурами данных ( лекция 5курса "Основы объектно-ориентированного проектирования"). Компонент start служит для перехода к первому элементу (если он есть), after - для выяснения того, имеются ли еще не пройденные элементы, forth - для перехода на одну позицию, item (определенный, если not after) - для выборки текущего элемента.

В попытке присваивания используется локальная сущность r типа RECTANGLE . Успех присваивания проверяется сравнением значения r с Void . Если r не Void , то r прямоугольник и можно обратиться к r.diagonal . Эта схема проверки вполне типична.

Заметим, что мы никогда не нарушаем правило Вызова Компонентов: обращения к r.diagonal защищены дважды: статически - компилятором, проверяющим, является ли diagonal компонентом класса RECTANGLE , и динамически - нашей гарантией того, что r не Void , а имеет присоединенный объект.

Обращение к элементу списка - потомку класса RECTANGLE , например SQUARE (квадрат), связывает r с объектом, и его диагональ будет участвовать в вычислениях.

Пример с универсальной функцией чтения объектов retrieval выглядит так:

my_last_book: BOOK

... Сравните с := в первой попытке

my_last_book ?= retrieved (my_book_file)

if my_last_book /= Void then

... "Обычные операции над my_last_book" ...

else

... "Полученное не соответствует ожиданию" ...

end

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

Заметьте, как тщательно был спроектирован механизм, дающий разработчикам шанс забыть об устаревшем стиле разбора вариантов (case-by-case). Если вы действительно хотите перехитрить динамическое связывание и отдельно проверять каждый вариант типа, вы можете это сделать, хотя вам и придется немало потрудиться. Так, вместо обычного f.display , использующего ОО-механизмы полиморфизма и динамического связывания, можно, - но нерекомендуется, - писать:

display (f: FIGURE) is

-- Отобразить f, используя алгоритм,

-- адаптируемый к истинной природе объекта.

local

r: RECTANGLE; t: TRIANGLE; p: POLYGON; s: SQUARE

sg: SEGMENT; e: ELLIPSE; c: CIRCLE;?

do

r ?= f; if r /= Void then "Использовать алгоритм вывода прямоугольника" end

t ?= f; if t /= Void then "Использовать алгоритм вывода треугольника" end

c ?= f; if c /= Void then "Использовать алгоритм вывода окружности" end

... и т.д. ...

end

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

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