Различия между дизайном по контракту и защитным программированием

Может ли Проектирование по контракту (DbC) быть способом защитного программирования?

Является ли один способ программирования лучше в некоторых случаях, чем другой?

design-patterns contract defensive-programming

Ответы:

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

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

Примечание: конечно, возможно, что в DbC кто-то еще проверит контракт. Например, в Eiffel система контрактов проверяет наличие отрицательного числа во время выполнения и выдает соответствующее исключение. В Spec # средство проверки теорем проверит наличие отрицательных чисел во время компиляции и завершит сборку, если не сможет доказать, что подпрограмма никогда не получит отрицательное число. Разница в том, что программист не делает эту проверку.

— Йорг Миттаг
источник

Может ли Проектирование по контракту (DbC) быть способом защитного программирования?

Да.

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

Определите договор и покончите с ним.

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

Можно показать, что «Защитное программирование» и «Предотвращение ошибок» добавляют ошибки (потому что проверки предотвращения ошибок сами по себе ошибочны), а не предотвращают ошибки.

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

— С. Лотт
источник

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

— Томас Оуэнс

@ThomasOwens: Это звучит как «Хорошая разработка программного обеспечения». Я только когда-либо видел, чтобы защитное программирование использовалось в качестве предлога для написания большого количества операторов IF (или утверждений), которые терпят неудачу до того, как обычно возникают исключения. Я бы не назвал ваш длинный список действительно хороших идей «Защитным программированием». Я бы назвал ваш список хороших идей "Программирование". Таким образом, мы можем отделить трату времени от всех умных вещей, которые вы перечислите.

— S.Lott

Я предпочитаю называть эти «хорошими идеями при написании кода» самостоятельно, но когда меня учили о защитном программировании, меня учили, что оно относится ко всем без исключения методам с явной целью обеспечения безопасности, надежности и надежности системы. , Может быть, это слишком широкое определение, или, может быть, это неправильное определение, но это то, чему меня учили. Я видел, как люди называют операторы и утверждения «защитным программированием», но, исходя из определения, которому меня учили, я бы не назвал это так (кроме случаев, когда у вас не обязательно есть лучшие варианты, такие как исключения).

— Томас Оуэнс

@ThomasOwens: «Может быть, это слишком широкое определение». Согласен. Похоже, отличный контрольный список хороших идей.

— S.Lott

-1: я не понимаю, как DbC - это способ защитного программирования, они в основном противоположны. Я сомневаюсь, что защитное программирование - это обычное дело, чтобы тратить время. И «можно показать, что он добавляет ошибки», нужна цитата, потому что это совсем не очевидно.

— Mark