Відмінності між дизайном за контрактом та захисним програмуванням


Відповіді:


30

Дизайн за допомогою контракту та оборонне програмування є в деякому сенсі протилежними один одному: у DbC ви визначаєте договори між співробітниками і програмуєте, припускаючи, що колабораціоністи виконують свої контракти. В оборонному програмуванні ви програмуєте за умови, що ваші співробітники порушують договори.

Справжній квадратний рутовий порядок, написаний у стилі DbC, зазначає у своєму договорі, що вам заборонено переходити у від'ємному числі, а потім просто припускати, що він ніколи не може зустріти негативне число. Справжній квадратний рут, написаний захисно, припускає, що він передається від'ємним числом і вживає відповідних заходів безпеки.

Примітка. Звичайно, можливо, що в DbC хтось інший перевірить контракт. Наприклад, у Ейфелі, система контрактів перевіряла б негативну кількість під час виконання і видала відповідне виняток. У Spec # довідник теореми перевірив би чи немає від'ємних чисел під час компіляції і не зможе збірку, якщо вона не зможе довести, що звичайна ніколи не буде передана від'ємним числом. Різниця полягає в тому, що програміст не проводить цю перевірку.


7

Чи може проектування за контрактом (DbC) бути способом програмувати обороно?

Так.

"Оборонне програмування" часто є приводом для того, щоб витрачати час. Він часто витрачає час на перевірку речей, що спричинить звичайні винятки. Замість винятків замість пунктів оброблення винятків пишуться додаткові заяви IF.

Визначте договір і виконайте його.

Коли хтось порушує контракт, програма - у звичайному ході подій - порушує і спричиняє нормальні винятки, з якими можна нормально працювати.

"Захисне програмування" та "Запобігання помилкам" можуть бути показані для додавання помилок (тому що перевірки запобігання помилкам самі по собі є помилковими), а не запобігають помилкам.

Обробка винятків може замовчувати, записувати та обробляти виняток набагато краще, ніж "Оборонне програмування".


6
Оборонне програмування - це більше, ніж просто, якщо заяви. Він включає огляди коду, статичний аналіз, аудит безпеки, вказівки щодо безпечного кодування тощо. Крім того, використання винятків та обробки винятків (на відміну від простого дозволу програми до краху та спалювання) вважається оборонною методикою програмування.
Томас Оуенс

2
@ThomasOwens: Це звучить як "Гарна розробка програмного забезпечення". Я коли-небудь бачив захисне програмування, яке використовується як привід для написання безлічі тверджень (або тверджень), які не вдається перед тим, як винятки зазвичай піднімаються. Я б не назвав ваш довгий список дійсно хороших ідей "Оборонним програмуванням". Я б назвав ваш список хороших ідей "Програмуванням". Таким чином, ми можемо відокремити втрату часу від усіх перелічених вами розумних речей.
S.Lott

2
Я вважаю за краще називати ці "хороші ідеї під час написання коду", але коли мене навчали про оборонне програмування, мене вчили, що він посилається на будь-які та всі методи з чіткими цілями забезпечення безпеки, безпеки та надійності системи . Можливо, це занадто широке визначення, або, можливо, це неправильне визначення, але це те, чого мене вчили. Я бачив, як люди називають висловлювання і твердження "оборонним програмуванням", але, виходячи з визначення, яке я вчив, я б не називав це таким (за винятком випадків, коли у вас не обов'язково є кращі варіанти, як винятки).
Томас Оуенс

@ThomasOwens: "Можливо, це занадто широке визначення". Погодьтеся. Це здається чудовим контрольним списком хороших ідей.
С.Лотт

2
-1: Я не бачу, як DbC - це спосіб програмувати оборонно, вони в основному протидіють. Сумніваюсь, звичайно робити оборонне програмування просто для того, щоб витрачати час. І "може бути показано, щоб додати помилки", потребує цитування, оскільки це зовсім не очевидно.
Марк
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.