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

Вызовы и пустые ссылки

Вызовы и пустые ссылки

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

some_entity.some_feature (arg1, ...)

Для корректного выполнения вызова сущность some_entity должна быть присоединена к нужному целевому объекту. Если случится, что some_entity ссылочного типа и имеет значение void , то вызов не может быть обработан, так как необходим целевой объект.

ОО-система никогда не должна в момент выполнения вызывать компонент с целевым объектом void . Результатом подобного вызова будет исключение (exception).(Исключения и их обработка будут изучаться в лекции 12)

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

if "x не void" then
x.f (...)
else
...
end

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

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

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

[x]. Если остаются малейшие сомнения, то поставлять ПО с механизмом обработки исключений.

Оглавление книги