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

Как уже было сказано, утверждение A называется более сильным, чем B , если A логически влечет B , но отличается от него: например, x >= 5 сильнее, чем x >= 0 . Если утверждение A сильнее утверждения B , говорят еще, что утверждение B слабее утверждения A .

Теперь нам понятно, как обманывать. Но как же быть честным? Объявляя подпрограмму повторно, мы можем сохранить ее исходные утверждения, но также мы вправе:

[x].заменить предусловие более слабым;

[x].заменить постусловие более сильным.

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

Итак, основное правило:

Правило (1) Утверждения Переобъявления (Assertion Redeclaration)

При повторном объявлении подпрограммы предусловие может заменяться лишь равным ему или более слабым, постусловие - лишь равным ему или более сильным.

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

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

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

Как следствие, создатель класса должен быть осторожным при написании утверждений эффективной подпрограммы, не привнося излишнюю спецификацию (overspecification). Утверждения должны описывать намерения подпрограммы, - ее абстрактную семантику, - но не свойства реализации. Иначе можно закрыть возможность создания иной реализации подпрограммы у будущих потомков.

Предположим, я написал класс MATRIX , реализующий операции линейной алгебры. Среди прочих возможностей я предлагаю своим клиентам подпрограмму расчета обратной матрицы. Фактически это сочетание команды и двух запросов: процедура invert инвертирует матрицу, присваивает атрибуту inverse значение обратной и устанавливает логический атрибут inverse_valid . Значение атрибута inverse имеет смысл тогда и только тогда, когда inverse_valid является истинным; в противном случае матрицу инвертировать не удалось, так как она вырождена. В ходе нашего обсуждения случай вырожденной матрицы мы можем проигнорировать.

Конечно же, я могу найти лишь приближенное значение обратной матрицы и готов гарантировать определенную точность расчетов, однако, не владея численными подпрограммами в совершенстве, буду принимать лишь запросы с точностью не выше 10 -6. В итоге, моя подпрограмма будет выглядеть приблизительно так:

invert (epsilon: REAL) is

-- Обращение текущей матрицы с точностью epsilon

require

epsilon >= 10 ^ (-6)

do

"Вычисление обратной матрицы"

ensure

((Current * inverse) |-| One) <= epsilon

end

Постусловие предполагает, что класс содержит инфиксную функцию infix "|-|" такую, что m1 |-| m2 есть |m1 - m2| (норма разности матриц m1 и m2 ), а также функцию infix "*" , результатом которой является произведение двух матриц. One - единичная матрица.

Как человек негордый, летом я приглашу программиста, и он перепишет мою подпрограмму invert , используя более удачный алгоритм, лучше аппроксимирующий результат и допускающий меньшее значение epsilon (как повторное объявление, эта запись синтаксически некорректна: