Основы объектно-ориентированного программирования [Ю. А. Блинков] (pdf) читать постранично, страница - 61

то класс перестает быть связан постусловием. В этом случае программа может делать все что угодно, например зациклиться, не нарушая при этом контракт. Это тот
самый случай, когда "заказчик виноват".
Первое преимущество от такого соглашения в том, что стиль программирования существенно
упрощается. Разработчик класса при написании тела программы смело может предполагать, что все
ограничения, заданные предусловием, выполняются; ему нет нужды проверять их в теле программы.
Так для функции, вычисляющей квадратный корень:
def sqrt(x):
assert x >= 0
.....

можно смело применять алгоритм, не учитывающий случай отрицательного x, поскольку это предусмотрено предусловием, и ответственность за его выполнение несут клиенты программы. С первого
взгляда это может показаться опасным, но читайте дальше. Фактически метод Проектирования по
Контракту идет дальше. Предположим, что мы написали в предложении do предыдущей программы
следующий текст:
...
if x < 0:
print "Обработать ошибку как-нибудь"
else:
print "Выполнить нормальное вычисление квадратного корня"
....
Заметьте, в этом не только нет никакой необходимости, но это и неприемлемо! Этот факт можно
отразить в следующем методологическом правиле:
Принцип Нет-Избыточности
Ни при каких обстоятельствах в теле программы не должно проверяться ее предусловие
Это правило противоречит тому, чему учат во многих учебниках по программирования, где необходимость проверок часто выступает под знаменами "защитного программирования"(defensive programming).
Его идея в том, что для получения надежного ПО каждая программа должна защищать себя настолько, насколько это возможно. Лучше больше проверок, чем недостаточно; нельзя доверять незнакомцам; еще одна проверка может и не поможет, но и не навредит делу.
Проектирование по контракту утверждает противное: избыточные проверки могут нанести вред.
Конечно, это кажется странным, на первый взгляд. Это естественная реакция, полагать, что дополнительная проверка в худшем случае может быть бесполезной, но не может быть причиной

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