Różnice między projektowaniem według umowy a programowaniem obronnym

26

Czy projektowanie na podstawie umowy (DbC) może być sposobem na programowanie defensywne?

Czy w niektórych przypadkach jeden sposób programowania jest lepszy od drugiego?

Gabriel Fair
źródło

Odpowiedzi:

30

Projektowanie na podstawie umowy i programowanie obronne są w pewnym sensie przeciwieństwami: w DbC definiujesz umowy między współpracownikami i programujesz przy założeniu, że współpracownicy honorują ich umowy. W programowaniu obronnym programujesz, zakładając, że współpracownicy naruszają ich umowy.

Rzeczywista funkcja pierwiastka kwadratowego napisana w stylu DbC stwierdziłaby w swojej umowie, że nie wolno przekazać liczby ujemnej, a następnie po prostu założyć, że nigdy nie napotka liczby ujemnej. Rzeczywista funkcja pierwiastka kwadratowego napisana obronnie zakłada, że ​​jest ona przekazywana przez liczbę ujemną i podejmuje odpowiednie środki ostrożności.

Uwaga: oczywiście jest możliwe, że w DbC ktoś inny sprawdzi umowę. Na przykład w Eiffelu system kontraktu sprawdzałby liczbę ujemną w czasie wykonywania i generowałby odpowiedni wyjątek. W Spec #, sprawdzający twierdzenie sprawdzałby liczby ujemne w czasie kompilacji i nie udałby się kompilacji, jeśli nie może udowodnić, że procedura nigdy nie przejdzie liczby ujemnej. Różnica polega na tym, że programista nie sprawdza tego.

Jörg W Mittag
źródło
7

Czy projektowanie na podstawie umowy (DbC) może być sposobem na programowanie defensywne?

Tak.

„Programowanie defensywne” jest często pretekstem do marnowania czasu. Często marnuje czas na sprawdzanie rzeczy, które spowodują zwykłe wyjątki. Zamiast wyjątków zapisywane są dodatkowe instrukcje IF zamiast klauzul dotyczących obsługi wyjątków.

Zdefiniuj kontrakt i skończ z nim.

Gdy ktoś naruszy umowę, program - w normalnym toku wydarzeń - złamie i podniesie normalne wyjątki, z którymi normalnie można sobie poradzić.

„Defensywne programowanie” i „Zapobieganie błędom” mogą być wyświetlane w celu dodawania błędów (ponieważ same kontrole zapobiegania błędom są błędne), a nie zapobiegania błędom.

Obsługa wyjątków może wyciszyć, zarejestrować i obsłużyć wyjątek znacznie lepiej niż „Programowanie defensywne”.

S.Lott
źródło
6
Programowanie obronne to coś więcej niż tylko instrukcje. Obejmuje przeglądy kodu, analizy statyczne, audyty bezpieczeństwa, wskazówki dotyczące bezpiecznego kodowania i wiele innych. Ponadto stosowanie wyjątków i obsługa wyjątków (w przeciwieństwie do zwykłego pozwalania programowi na awarię i nagrywanie) jest uważana za technikę programowania obronnego.
Thomas Owens
2
@ThomasOwens: To brzmi jak „Good Software Development”. Widziałem tylko programowanie defensywne jako pretekst do napisania wielu instrukcji IF (lub twierdzeń), które zawodzą, zanim normalnie pojawią się wyjątki. Nie nazwałbym twojej długiej listy naprawdę dobrych pomysłów „programowaniem obronnym”. Nazwałbym twoją listę dobrych pomysłów „Programowaniem”. W ten sposób możemy oddzielić marnowanie czasu od wszystkich inteligentnych rzeczy, które wymieniasz.
S.Lott,
2
Wolę nazywać te „dobrymi pomysłami podczas pisania kodu”, ale kiedy nauczono mnie programowania defensywnego, nauczono mnie, że odnosi się ono do wszelkich technik mających na celu zapewnienie bezpieczeństwa, ochrony i niezawodności systemu . Może to zbyt szeroka definicja, a może to zła definicja, ale tego mnie nauczono. Widziałem, jak ludzie nazywają twierdzenia i twierdzenia „programowaniem obronnym”, ale w oparciu o definicję, której mnie nauczono, nie nazwałbym tego tak (z wyjątkiem przypadków, w których niekoniecznie masz lepsze opcje, takie jak wyjątki).
Thomas Owens
@ThomasOwens: „Może to zbyt szeroka definicja”. Zgodzić się. Wygląda na świetną listę kontrolną dobrych pomysłów.
S.Lott
2
-1: Nie rozumiem, jak DbC jest sposobem na programowanie defensywne, są w zasadzie przeciwieństwami. Wątpię, żeby programowanie w obronie było po prostu marnowaniem czasu. I „można pokazać, że dodaje błędy” wymaga cytowania, ponieważ wcale nie jest to oczywiste.
Mark