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

Причина близости нотаций в том, что присваивание зачастую кратчайший путь достижения эквивалентности. Но при переходе к более сложным примерам концептуальное различие между спецификацией и реализацией будет только возрастать. Даже в простейшем случае вычисления квадратного корня постусловие может быть задано в форме: abs(Result^2 -x) <= tolerance , где abs - обозначает абсолютное значение, а tolerance - допустимое отклонение от точного значения. Инструкции, вычисляющие квадратный корень, могут быть не тривиальными, реализуя определенный алгоритм вычисления квадратного корня.

Даже для put в классе STACK2 одной и той же спецификации могут соответствовать различные алгоритмы, например:

if count = capacity then Result := True else Result := False end

или упрощенный вариант, учитывающий правила инициализации:

if count = capacity then Result := True end

В ходе работы мы столкнулись со свойством утверждений, заслуживающим дальнейшей проработки: оно важно для авторов клиентских классов, не интересующихся реализацией, но нуждающихся в абстрактном описании роли программы. Эта идея приведет нас к понятию краткой формы (short form), обсуждаемой далее в этой лекции в качестве основного механизма документирования класса.

Предупреждение: по практическим соображениям допускается включение в утверждение функций - по внешнему виду императивных элементов. Эта проблема исследуется в конце этой лекции.

В заключение обсуждения полезно перечислить слова, используемые по контрасту в двух категориях программных элементов:

Таблица 11.2.Императивно - аппликативное противопоставление

Предусловие в процедуре создания (конструкторе) make класса STACK1 требует комментария. Оно устанавливает n>=0 и, следовательно, допускает пустые стеки. Если n=0 , то make вызовет процедуру создания для массивов, также имеющую имя make , с аргументами 1 и 0 для нижней и верхней границ соответственно. Это не ошибка, это соответствует спецификации процедуры создания массивов, которая в случае, когда нижняя граница на единицу больше верхней, создает пустой массив.

Пустой стек не ошибка, это особый случай. Ошибка может возникнуть при попытке чтения из пустого стека, но этот случай охраняется предусловиями put и item .

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

Центральная идея Проектирования по контракту выражена в принципе Нет_Избыточности, суть которого в том, что за выполнение условия, необходимого для правильного функционирования программы, должен нести ответственность только один из партнеров контракта.

Какой же? В каждом случае есть две возможности.

[x].Ответственность возлагается на клиента. В этом случае условие становится частью предусловия программы.

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

Первую ситуацию назовем требовательной ( demanding), вторую - толерантной ( tolerant). Класс STACK2 иллюстрирует требовательный стиль, толерантная версия, не содержащая предусловий, может выглядеть так:

remove is

-- Удалить элемент вершины стека

do

if empty then

print ("Ошибка: попытка удаления элемента из пустого стека")

else

count := count - 1

end

end

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