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

Пусть новый класс A' порожден от A и содержит повторное объявление r . Как он может, если вообще может, заменить прежнее предусловие новым γ , а прежнее постусловие β - новым ?

Чтобы найти ответ, рассмотрим обязательства клиента. В вызове a1.r цель a1 может - в силу полиморфизма - иметь тип A' . Однако C об этом не знает! Единственным объявлением a1 остается исходная строка

a1: A

где упоминается A , но не A' . На деле C может использовать A' , даже если его автор не знает о наличии такого класса. Вызов подпрограммы r может произойти, например, в процедуре C вида:

some_routine_of_C (a1: A) is

do

...; a1.r;...

end

Тогда при вызове some_routine_of_C из другого класса в нем может использоваться фактический параметр типа A' , даже если в тексте клиента C класс A' нигде не упоминается. Динамическое связывание как раз и означает тот факт, что обращение к r приведет в этом случае к использованию переопределенной версии A' .

Итак, может сложиться ситуация, в которой C , являясь только клиентом A , фактически во время выполнения использует версии компонентов класса A' . (Можно сказать, что C - "динамический клиент" A' , хотя в тексте C об этом и не говорится.)

Что это значит для C ? Только одно - проблемы, которые возникнут, если не предпринять никаких действий. Клиент C может добросовестно выполнять свою часть контракта, и все же в результате он будет обманут. Например,

if a1. then a1.r end

если a1 полиморфно присоединена к объекту типа A' , инструкция вызовет подпрограмму, ожидающую выполнения γ и гарантирующую выполнение , в то время как клиент получил указание соблюдать и ожидать выполнения β . Налицо возможное расхождение во взглядах клиента и поставщика на контракт.

Чтобы понять, как удовлетворить клиентов, мы должны сыграть роль адвокатов дьявола и на секунду представить себе, как их обмануть. Так поступает опытный криминалист, разгадывая преступление. Как мог бы поступить поставщик, желающий ввести в заблуждение своего честного клиента C , гарантирующего при вызове и ожидающего выполнения β ? Есть два пути:

[x]. Потребовать больше, чем предписано предусловием Вспомните, что мы неоднократно говорили при обсуждении Проектирования по Контракту: усиление предусловия облегчает задачу поставщика ("клиент чаще не прав"), иллюстрацией чего служит крайний случай - предусловие false(когда "клиент всегда не прав").

Как уже было сказано, утверждение 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 - единичная матрица.