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

Утверждения это не управляющие структуры

Утверждения это не управляющие структуры

Еще одно типичное заблуждение - рассматривать утверждения как управляющую структуру, реализующую разбор случаев. К этому моменту должно быть ясно, что не в этом их роль. Если написать программу sqrt, в которой отрицательные значения будут обрабатываться одним способом, а положительные - другим, то писать предусловие - предложение require не следует. В этом случае используется обычный разбор случаев: оператор if - then - else, или оператор case языка Pascal, или оператор inspect, введенный в этой книге как раз для таких целей.

Утверждения выражают нечто иное. Они говорят о корректности условий. Если sqrt имеет предусловие, то вызов, в котором x<0, это "жучок" (bug).

Правило нарушения утверждения (1)

Нарушение утверждения в период выполнения является проявлением "жучка" в ПО.

Слово "жучок" не принадлежит к научному лексикону, но этот термин понятен всем программистам. Учитывая контракты, это правило можно уточнить:

Правило нарушения утверждения (2)

Нарушение предусловия является проявлением "жучка" у клиента.

Нарушение постусловия является проявлением "жучка" у поставщика.

Нарушение предусловия означает, что вызывающая программа нарушила контракт - "виноват заказчик". С позиций внешнего наблюдателя можно, конечно, критиковать сам контракт, но коль скоро контракт заключен, его следует выполнять. Если есть программа, осуществляющая мониторинг утверждений, то запускать на выполнение программу, чье предусловие не выполняется, не имеет смысла.

Нарушение постусловия означает, что программа, предположительно вызванная в корректных условиях, не выполнила свою часть работы, предусмотренную контрактом. Здесь тоже ясно, кто виноват, а кто нет: "жучок" в программе, клиент не виновен.

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