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

Работа с утверждениями

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

Класс стек

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

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

Рис. 11.2.  Реализация стека на базе массива

Массив, названный representation, имеет границы 1 и capacity: реализация использует также целочисленный атрибут count, отмечающий вершину стека. Заметьте, после того, как мы откроем для себя наследование, появится возможность писать классы с отложенной реализацией, что позволит покрывать несколько возможных реализаций, а не одну конкретную. Даже для класса c фиксированной реализацией, например, как здесь на базе массива, мы будем иметь возможность строить его как потомка родительского класса Array. В данный момент никакие методы наследования применяться не будут.

Вот он класс. Остается напомнить, что для массива a операция, присваивающая значение x его i-му элементу, записывается так: a.put(x,i). Получить i-й элемент можно так: a.item(i) или a @ i. Если, как здесь, границы заданы, то i во всех случаях лежит между этими границами: 1<= i <= capacity.

indexing
description: "Стеки: Структуры с политикой доступа Last-In, First-Out %
% Последний пришел - Первый ушел, и с фиксированной емкостью"
class STACK2 [G] creation
make
feature - Initialization (Инициализация)
make (n: INTEGER) is
-- Создать стек, содержащий максимум n элементов
require
positive_capacity: n >= 0
do
capacity := n
create representationlmake (1, capacity)
ensure
capacity_set: capacity = n
array_allocated: representation /= Void
stack_empty: empty
end
feature - Access (Доступ)
capacity: INTEGER
-- Максимальное число элементов стека
count: INTEGER
-- Число элементов стека
item: G is
-- Элемент на вершине стека
require
not_empty: not empty -- i.e. count > 0
do
Result := representation @ count
end
feature -- Status report (Отчет о статусе)
empty: BOOLEAN is
-- Пуст ли стек?
do
Result := (count = 0)
ensure
empty_definition: Result = (count = 0)
end
full: BOOLEAN is
-- Заполнен ли стек?
do
Result := (count = capacity)
ensure
full_definition: Result = (count = capacity)
end
feature -- Element change (Изменение элементов)
put (x: G) is
-- Добавить элемент x на вершину
require
not_full: not full -- т.е. count < capacity в этом представлении
do
count := count + 1
representation.put (count, x)
ensure
not_empty: not empty
added_to_top: item = x
one_more_item: count = old count + 1
in_top_array_entry: representation @ count = x
end
remove is
-- удалить элемент вершины стека
require
not_empty: not empty -- i.e. count > 0
do
count := count - 1
ensure
not_full: not full
one_fewer: count = old count - 1
end
feature {NONE} -- Implementation (Реализация)
representation: ARRAY [G]
-- Массив, используемый для хранения элементов стека
invariant
... Будет добавлен позднее ...
end

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

Это первый законченный класс этой лекции, не слишком далеко отличающийся от того, что можно найти в профессиональных библиотеках повторно используемых ОО-компонентов, таких как Базовые библиотеки. Одно замечание о структуре класса. Поскольку класс имеет более двух-трех компонентов, возникает необходимость сгруппировать его компоненты подходящим образом. Нотация позволяет реализовать такую возможность введением множества предложений feature. Это свойство группировки компонентов, введенное в предыдущей лекции, использовалось там, как способ задания различного статуса экспорта компонентов. И здесь в последней части класса, помеченной Implementation, это свойство используется для указания защищенности компонента representation. Но преимущества группирования можно использовать и при неизменном статусе экспорта. Его цель - сделать класс простым при чтении и легче управляемым, группируя компоненты по категориям. После каждого ключевого слова feature появляется комментарий, называемый комментарий к предложению Feature (Feature Clause Comment). Он позволяет дать содержательное описание данной категории - роль компонентов, включенных в этот раздел. Категории, используемые в примере, те же, что и при описании класса STACK1 с добавлением раздела Initialization с процедурой создания (конструктором).

Стандартные категории feature и связанные с ними комментарии к предложениям Feature являются частью общих правил организации повторно используемых библиотек классов.

Императив и аппликатив (применимость)

Утверждения из STACK2 иллюстрируют фундаментальную концепцию - разницу между императивным и аппликативным видением.

Утверждения empty и full могут вызвать удивление. Приведу еще раз текст full:

full: BOOLEAN is
-- Заполнен ли стек?
do
Result := (count = capacity)
ensure
full_definition: Result = (count = capacity)
end

Постусловие говорит, что Result имеет значение выражения (count = capacity). Но оператор присваивания именно это значение присваивает переменой Result. В чем же смысл написания постусловия? Не является ли оно избыточным?

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

Инструкция предписывает (prescriptive), утверждение описывает (descriptive). Инструкция описывает "как", утверждение описывает "что". Инструкция является частью реализации, утверждение - элементом спецификации.

Инструкция императивна, утверждение - аппликативно. Эти два термина выражают фундаментальную разницу между программированием и математикой.

[x]. Компьютерные операции могут изменять состояние аппаратно-программной машины. Инструкции в языках программирования являются командами (императивные конструкции), заставляющие машину выполнять такие операции.

[x]. Математические вычисления никогда ничего не меняют. Как отмечалось при рассмотрении АТД, взятие квадратного корня от числа 2 не меняет это число. Вместо этого математики описывают как, используя свойства одних объектов, вывести свойства других, таких как v2, полученных применением (applying - отсюда и термин "аппликативный") математических трансформаций.

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

Причина близости нотаций в том, что присваивание зачастую кратчайший путь достижения эквивалентности. Но при переходе к более сложным примерам концептуальное различие между спецификацией и реализацией будет только возрастать. Даже в простейшем случае вычисления квадратного корня постусловие может быть задано в форме: 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

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

Рис. 11.3.  Реклама толерантного стиля

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

Исследуем эту проблему чуть глубже. Условие корректности описывает требования, необходимые для успешной работы программы. Толерантная версия программы remove является хорошим примером, демонстрирующим слабости этого стиля. Действительно, что может сделать бедная, занимающаяся выталкиванием программа, когда стек пуст? Она делает храбрую попытку выдать явно неинформативное сообщение об ошибке, но на большее она не способна - ей недоступен контекст клиента, она не способна определить, что нужно делать, когда стек пуст. Только клиент - модуль, использующий стек для своих целей, например, модуль разбора текста в компиляторе, - обладает достаточной информацией для принятия нужного решения. Является ли это нормальным, хотя и бесполезным запросом, который следует просто проигнорировать. Если это ошибка, как следует ее обработать: выбросить ли исключение, попытаться скорректировать ситуацию, или, в крайнем случае, выдать информативное для пользователя сообщение об ошибке.

Обсуждая пример с квадратным корнем, приводился такой вариант программы:

if x < 0 then
"Обработайте ошибку как-нибудь"
else
"Выполнить нормальное вычисление квадратного корня"
end

Ключевое слово здесь "как-нибудь". Предложение then скорее заклинание, чем программный код: нет разумной, общецелевой техники обработки случая x<0. Только автор клиента может знать, что значит этот случай - ошибка в ПО, возможность замены нулевым значением, причина для возбуждения исключения...

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

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

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

Принцип обоснованности предусловия

Каждое предусловие программы при требовательном стиле проектирования должно удовлетворять следующим требованиям:

1 Предусловие появляется в официальной документации, поставляемой авторам клиентских модулей.

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

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

Некоторые ограничения могут навязываться реализацией. Например, в программе put из класса STACK2 присутствие в качестве предусловия require not full связано с реализацией стека на основе массива. Но это не является нарушением принципа, поскольку класс STACK2 в полном соответствии с его спецификацией определяет стеки ограниченной емкости, что отражено, например, в предложении indexing этого класса. АТД, служащий в роли спецификации этого класса, не задает наиболее общий вид стеков, но является понятием стека ограниченной емкости.

Предусловия и статус экспорта

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

Рассмотрим следующую ситуацию:

-- Предупреждение: это неправильный класс, только в целях иллюстрации.
class SNEAKY feature
tricky is
require
accredited
do
...
end
feature {NONE}
accredited: BOOLEAN is do ... end
end

Спецификация для tricky устанавливает, что любой вызов этой процедуры должен удовлетворять условию, выраженному булевой функцией accredited. Но при экспорте класса эта функция для клиентов является закрытой, поэтому у них нет способа проверить выполнимость условия перед вызовом tricky. Очевидно, подобная ситуация неприемлема.

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

Это правило учитывает все возможные ситуации экспорта, а не только случаи доступности всем клиентам (tricky) или полной недоступности (accredited). Как отмечалось, при обсуждении проблемы скрытия информации, компонент класса можно сделать доступным для некоторых клиентов, явно перечислив их в feature предложении, например feature {A, B, ... }, определяющего доступность только для классов A, B, ... и их потомков. Сформулируем правило языка:

Правило Доступности предусловия

Каждый компонент, появляющийся в предусловии программы, должен быть доступен каждому клиенту, которому доступна сама программа.

В соответствии с этим правилом каждый клиент, способный вызвать программу, способен проверить ее предусловие. По этому правилу класс SNEAKY является коварным, некорректно построенным, поскольку экспортирует tricky с недоступным предусловием. Нетрудно превратить этот класс в правильно построенный, изменив статус экспорта у accredited. Если tricky появится с предложением feature в форме feature {A, B, C}, то accredited должна экспортироваться, по меньшей мере, клиентам A, B, C, появляясь в той же группе feature, что и tricky. Можно задать для accredited собственное feature-предложение в одной из форм: feature {A, B, C}, feature {A, B, C, D, ...} или просто feature. Любое нарушение этого правила приведет к ошибке в период компиляции. Класс SNEAKY, например, будет забракован компилятором.

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

put (x: G) is
-- Добавить элемент x на вершину
require
not full
do
...
ensure
... Другие предложения...
in_top_array_entry: representation @ count = x
end

Последнее предложение в постусловии устанавливает, что элемент массива с индексом count содержит последний втолкнутый в стек элемент. Это свойство реализации, хотя put обычно доступно (экспортируется всем клиентам), массив representation является закрытым. Но ничего ошибочного в постусловии нет. Оно просто включает наряду со свойствами, полезными для клиентов ("Другие предложения"), свойство, имеющее смысл только для тех, кто знаком с полным текстом класса. Такие закрытые предложения не будут появляться в краткой форме класса - документации, предназначенной для авторов клиентских модулей.

Толерантные модули

(При первом чтении этот раздел можно опустить или ограничиться его беглым просмотром.)

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

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

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

a, b, c, ...: INTEGER is unique

то в результате этого объявления a, b, c получат последовательно идущие целочисленные значения. Эти значения будут даваться компилятором с гарантией того, что все объявленные таким образом константы получат различные значения (будут уникальными). По принятому соглашению, всем объявляемым таким образом константам даются имена, начинающиеся с буквы в верхнем регистре и с остальными символами в нижнем регистре, например Underflow.

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

indexing
description: "Стеки: Структуры с политикой доступа Last-In, First-Out %
%Первый пришел - Последний ушел, с фиксированной емкостью; %
%толерантная версия, устанавливающая код ошибки в случае %
%недопустимых операций."
class STACK3 [G] creation
make
feature - Initialization (Инициализация)
make (n: INTEGER) is
-- Создать стек, содержащий максимум n элементов, если n > 0;
-- в противном случае установить код ошибки равным Negative_size.
-- Без всяких предусловий!
do
if capacity >= 0 then
capacity := n
create representation.make (capacity)
else
error := Negative_size
end
ensure
error_code_if_impossible: (n < 0) = (error = Negative_size)
no_error_if_possible: (n >= 0) = (error = 0)
capacity_set_if_no_error: (error = 0) implies (capacity = n)
allocated_if_no_error: (error = 0) implies (representation /= Void)
end
feature - Access (Доступ)
item: G is
-- Элемент вершины, если существует; в противном случае
-- значение типа по умолчанию.
-- с ошибкой категории Underflow.
-- Без всяких предусловий!
do
if not empty then
check representation /= Void end
Result := representation.item
error := 0
else
error := Underflow
-- В этом случае результатом является значение по умолчанию
end
ensure
error_code_if_impossible: (old empty) = (error = Underflow)
no_error_if_possible: (not (old empty)) = (error = 0)
end
feature -- Status report (Отчет о статусе)
empty: BOOLEAN is
-- Пуст ли стек?
do
Result := (capacity = 0) or else representation.empty
end
error: INTEGER
-- Индикатор ошибки, устанавливаемый различными компонентами
-- в ненулевое значение, если они не могут выполнить свою работу
full: BOOLEAN is
-- Заполнен ли стек?
do
Result := (capacity = 0) or else representation.full
end
Overflow, Underflow, Negative_size: INTEGER is unique
-- Возможные коды ошибок
feature -- Element change (Изменение элементов)
put (x: G) is
-- Добавить x на вершину, если возможно; иначе задать код ошибки.
-- Без всяких предусловий!
do
if full then
error := Overflow
else
check representation /= Void end
representation.put (x); error := 0
end
ensure
error_code_if_impossible: (old full) = (error = Overflow)
no_error_if_possible: (not old full) = (error = 0)
not_empty_if_no_error: (error = 0) implies not empty
added_to_top_if_no_error: (error = 0) implies item = x
one_more_item_if_no_error: (error = 0) implies count = old count + 1
end
remove is
-- Удалить вершину, если возможно; иначе задать код ошибки.
-- Без всяких предусловий!
do
if empty then
error := Underflow
else
check representation /= Void end
representation.remove
error := 0
end
ensure
error_code_if_impossible: (old empty) = (error = Underflow)
no_error_if_possible: (not old empty) = (error = 0)
not_full_if_no_error: (error = 0) implies not full
one_fewer_item_if_no_error: (error = 0) implies count = old count - 1
end
feature {NONE} - Implementation (Реализация)
representation: STACK2 [G]
-- Незащищенный стек используется для реализации
capacity: INTEGER
-- Максимальное число элементов стека
end - class STACK3

Операции этого класса не имеют предусловий (более точно, имеют True в качестве предусловия). Результат выполнения может характеризовать ненормальную ситуацию, постусловие переопределено так, чтобы позволить отличать корректную и ошибочную обработку. Например, при вызове s.remove, где s это экземпляр класса STACK3, в корректной ситуации значение s.error будет равно 0; в ошибочной - Underflow. В последнем случае никакая другая работа выполняться не будет. Клиент несет ответственность за проверку s.error после вызова. Как уже отмечалось, у общецелевого модуля, такого как STACK3 нет способа решить, что делать в ошибочной ситуации: выдать сообщение об ошибке, произвести корректировку ситуации...

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

Несколько технических замечаний к приведенному примеру класса.

[x]. Экземпляр STACK3 - содержит атрибут representation, представляющий ссылку на экземпляр STACK2, содержащий, в свою очередь, ссылку на массив. Эти обходные пути пагубно отражаются на эффективности, избежать этого можно введением наследования, изучаемого в последующих лекциях.

[x]. Булева операция or else подобна or, но если первый операнд равен True, игнорирует второй операнд, возможно неопределенный в такой ситуации.

[x]. Инструкция check, используемая в put и remove, служит для проверки выполнения некоторых утверждений. Она будет изучаться позднее в этой лекции.

В заключение: вы, наверное, отметили тяжеловесность STACK3 в сравнении с простотой STACK2, достигнутой благодаря предусловиям. Это хороший пример, показывающий, что толерантный стиль может приводить к бесполезно усложненному ПО. Требовательный стиль, по контрасту, вытекает из общего духа Проектирования по контракту. Попытка управлять всем, - и возможными и невозможными случаями - совсем не лучший способ помочь вашим клиентам. Если вместо этого вы построите классы, влекущие возможно более строгие условия на их использование, точно опишите эти условия, включив их в документацию класса, вы реально облегчите жизнь вашим клиентам. Требовательная любовь (tough love) может быть лучше всепрощающей; лучше эффективная поддержка функциональности с проверяемыми ограничениями, чем страстная попытка предугадать желания клиентов, принятие возможно неадекватных решений, жертвой чего становятся простота и эффективность.

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

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