Правильное использование попытки присваивания

We use cookies. Read the Privacy and Cookie Policy

Правильное использование попытки присваивания

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

Заметьте, как тщательно был спроектирован механизм, дающий разработчикам шанс забыть об устаревшем стиле разбора вариантов (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

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

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

Немного похожий на попытку присваивания механизм "сужения" (narrowing) есть в языке Java. В случае несоответствия типов он выдает исключение. Это похоже на самоубийство, неуспех присваивания вовсе не является чем-то ненормальным, это ожидаемый результат. Оператор instanceof в языке Java выполняет проверку типов на совместимость.

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