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

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

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

Посему, хотя и следует думать о будущем, не следует забивать себе голову вопросами о возможной потере производительности из-за введения конструкции old. Должна ли система сохранять значения перед запуском программы, чтобы иметь возможность вычислять old выражения? Это зависит: в некоторых обстоятельствах (например, при тестировании и отладке) полезно вычислять утверждения; в других - (для полностью проверенных систем) их можно рассматривать как аннотации программного текста.

Все это учитывается в следующих разделах, являясь методологическим вкладом утверждений и метода Проектирование по Контракту - концептуального средства анализа, проектирования, реализации и документирования, помогающего нам построить ПО со встроенной надежностью (reliability is built-in), в терминологии Миллса строить корректную программу и знать это.

Контракты и надежность ПО

Предусловие и постусловие программы определяют контракт со всеми ее клиентами.

Права и обязательства

Связывая с программой r предложения require pre и ensure post, класс говорит своим клиентам:

"Если вы обещаете вызвать r в состоянии, удовлетворяющем pre, то я обещаю в заключительном состоянии выполнить post".

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

[x]. Предусловие связывает клиента: определяются условия, при которых вызов программы клиентом легитимен. Обязательства клиента приносят пользу поставщику.

[x]. Постусловие связывает класс: программа обязана обеспечить условия по ее завершению. Здесь польза клиента оборачивается обязательствами поставщика класса.

Вот пример контракта для одной из программ нашего примера:

(Выполнить предусловие:)

Вызывать put(x) только для непустого стека.

(Из постусловия:)

Получить обновленный стек: не пустой, x на вершине, (item дает x, count увеличилось на единицу).

(Выполнить постусловие:)

Обновить представление стека: иметь x на вершине (item возвращает x), count увеличить на единицу, стек не пуст.

(Из предусловия:)

Упрощающее обработку предположение о том, что стек не пуст.

Таблица 11.1.Контракт программы: программа put класса стек

Интуиция (Дзен) и искусство программной надежности: больше гарантий и меньше проверок

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

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

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

sqrt (x: REAL): REAL is

-- Квадратный корень из x

require

x >= 0

do ... end

можно смело применять алгоритм, не учитывающий случай отрицательного x, поскольку это предусмотрено предусловием, и ответственность за его выполнение несут клиенты программы. С первого взгляда это может показаться опасным, но читайте дальше. Фактически метод Проектирования по Контракту идет дальше. Предположим, что мы написали в предложении do предыдущей программы следующий текст:

if x < 0 then

"Обработать ошибку как-нибудь"

else

"Выполнить нормальное вычисление квадратного корня"

end

Заметьте, в этом не только нет никакой необходимости, но это и неприемлемо! Этот факт можно отразить в следующем методологическом правиле:

Принцип Нет-Избыточности

Ни при каких обстоятельствах в теле программы не должно проверяться ее предусловие

Это правило противоречит тому, чему учат во многих учебниках по программированию, где необходимость проверок часто выступает под знаменами "защитного программирования" (defensive programming). Его идея в том, что для получения надежного ПО каждая программа должна защищать себя настолько, насколько это возможно. Лучше больше проверок, чем недостаточно; нельзя доверять незнакомцам; еще одна проверка может и не поможет, но и не навредит делу.

Проектирование по контракту утверждает противное: избыточные проверки могут нанести вред. Конечно, это кажется странным, на первый взгляд. Это естественная реакция, полагать, что дополнительная проверка в худшем случае может быть бесполезной, но не может быть причиной неполадок. Возьмем, например, программу sqrt, включившую проверку x<0, хотя ее клиенты были проинструктированы о необходимости обеспечения x>=0. Что в этом плохого? С микроскопической точки зрения, ограничив наше видение узким мирком sqrt, кажется, что включение проверки делает программу более устойчивой. Но мир системы не ограничивается одной программой - он содержит множество программ в множестве классов. Для получения надежной системы необходимо перейти к макроскопическому видению проблемы, обобщающему всю архитектуру.

С этой глобальной точки зрения простота становится критическим фактором. Сложность - главный враг качества. Когда в этот концерн привносятся излишние проверки, то это уже не покажется столь безобидным делом. Экстраполируйте на тысячи программ в системе среднего размера (или на десятки и сотни тысяч в большой системе) проверку (if x<0 then ...), столь безобидную с первого взгляда, - все это начнет выглядеть подобно монстру бесполезной сложности. Добавляя избыточные проверки, добавляете больше кода. Больше кода - больше сложности, отсюда и больше источников условий, приводящих к тому, что все пойдет не так, это приведет к дальнейшему разрастанию кода и так до бесконечности. Если пойти по этой дороге, то определенно можно сказать одно - мы никогда не достигнем надежности. Чем больше пишем, тем больше придется писать.

Этот бег с препятствиями не для нас, нас ждет другая дорога. Проектирование по Контракту приглашает идентифицировать согласованные условия, необходимые для правильного функционирования каждого контракта в кооперации клиенты - поставщики. Метод вынуждает для каждого соглашения установить, кто несет ответственность - клиент или поставщик. Ответ может быть разный, частично он определяется стилем проектирования; позже будет дан ответ, как это делать лучшим образом. Но когда решение принято, нужно его придерживаться. Если требования корректности появляются в предусловии, определяя тем самым ответственность клиента, то в программе не должно быть соответствующих проверок. Требования, не указанные в предусловии, должны проверяться и выполняться в программе.