Проблема

Проблема

Из этих примеров ясно: нам может понадобиться механизм удостоверения типа объекта.

Решение этой проблемы, возникающей в специфических, но критически важных случаях, должно быть найдено без потери преимуществ ОО-стиля разработки. В частности, мы не хотим возвращаться к той схеме, которую сами и осудили:

if "f типа RECTANGLE" then

...

elseif "f типа CIRCLE" then

...

и т.д.

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

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

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