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

В таком случае, поскольку известно, что объект O2 является прямоугольником и доступен через имя прямоугольника r, зачем пытаться использовать доступ к его диагонали посредством операции p.diagonal? Это не имеет смысла, так как можно просто написать r.diagonal, использовав официальное имя прямоугольника и сняв все сомнения в правомерности применения его операций. Использование имени многоугольника p, которое может с тем же успехом обозначать треугольник, ничего не дает и приводит к неопределенности.

Действительно, полиморфизм теряет информацию: когда в результате присваивания p :=r появляется возможность ссылаться на прямоугольник O2 через имя многоугольника p, то теряется нечто важное - возможность использовать специфические компоненты прямоугольника. В чем тогда польза? В данном случае - ни в чем. Как уже отмечалось, интерес возникает, когда заранее неизвестно, каков будет вид многоугольника p после выполнения команды if some_condition then p:= r else p := something_else ... или когда p является формальным аргументом процедуры и неизвестно, каков будет тип фактического аргумента. Но в этих случаях было бы некорректно и опасно применять к p что-либо кроме компонентов класса POLYGON.

Продолжая тему животных, представим, что некто спрашивает: "У вас есть домашний любимец?" и вы отвечаете: "Да, кот!". Это похоже на полиморфное присваивание - один объект известен под двумя именами разных типов: "мой_домашний_любимец" и "мой_кот" обозначают сейчас одно животное. Но они не служат одной цели, первое имя является менее информативным, чем второе. Можно одинаково успешно использовать оба имени при звонке в отдел отсутствующих хозяев компании Любимцы-По-Почте ("Я собираюсь в отпуск, сколько будет стоить наблюдение за моим_домашним_любимцем (или: моим_котом) в течение двух недель?") Но при звонке в другой отдел с вопросом: "Могу ли я привезти во вторник моего домашнего любимца, чтобы отстричь когти?", вы не запишетесь на прием, пока не уточните, что имели в виду своего кота.

Когда хочется задать тип принудительно

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

При получении коробки с надписью "Животное" вместо ожидаемой надписи "Собака", можно соблазниться и все же ее открыть, зная, что, если внутри будет не собака, то потеряется право на возврат посылки и, в зависимости от того, что из нее появится, можно лишиться даже возможности рассказать эту историю.

В таких случаях требуется новый механизм - попытка присваивания, который позволит писать команду вида r ?= p (где ?= обозначает символ попытки присваивания, в отличие от := для обычного присваивания), означающую "выполнить присваивание, если тип объекта соответствует r, а иначе сделать r пустым". Но мы пока не готовы понять, как такая команда сочетается с ОО-методом, поэтому вернемся к этому вопросу в следующих лекциях. (А до того, считайте, что вы ничего об этом не читали).

Полиморфное создание

Введение наследования и полиморфизма приводит к небольшому расширению механизма создания объектов, который позволит непосредственно создавать объекты типов-потомков.

Напомним, что команды создания (процедуры-конструкторы) имеют один из следующих видов:

create x

create x.make (...)