契約による設計と防御的プログラミングの違い


回答:


30

契約による設計と防御的プログラミングは、ある意味で互いに反対です。DbCでは、共同制作者間の契約を定義し、共同制作者が契約を尊重するという前提でプログラミングします。防衛的プログラミングでは、共同制作者が契約に違反するという前提でプログラミングします。

DbCスタイルで記述された実際の平方根ルーチンは、負の数を渡すことは許可されておらず、負の数に遭遇することは絶対にないと仮定するという契約で述べています。防御的に記述された実際の平方根ルーチンは、負の数が渡されると想定し、適切な予防措置を講じます。

注:もちろん、DbCでは他の誰かが契約を確認する可能性があります。たとえば、エッフェルでは、契約システムは実行時に負の数をチェックし、適切な例外をスローします。Spec#では、定理証明者は、ルーチンが負の数を渡されないことを証明できない場合、コンパイル時に負の数をチェックし、ビルドに失敗します。違いは、プログラマーがこのチェックを行わないことです。


7

契約による設計(DbC)は、防御的にプログラムする方法になりますか?

はい。

「ディフェンシブプログラミング」は、多くの場合、時間を無駄にする言い訳です。多くの場合、通常の例外の原因となるものをチェックする時間を無駄にします。例外の代わりに、例外処理句の代わりに追加のIFステートメントが記述されます。

契約を定義して完了します。

誰かが契約に違反すると、プログラムは、通常のイベントの過程で、通常処理できる通常の例外を破り、発生させます。

「防御的プログラミング」と「エラー防止」は、エラーを防止するのではなく、エラーを追加するために表示できます(エラー防止チェック自体がエラーであるため)。

例外処理は、「Defensive Programming」よりもはるかに優れた例外を沈黙させ、記録し、処理することができます。


6
防御的プログラミングは、if文よりも萌えです。コードレビュー、静的分析、セキュリティ監査、安全なコーディングガイドラインなどが含まれます。さらに、例外の使用と例外処理(単にプログラムをクラッシュさせて焼き付けるのではなく)は、防御的なプログラミング手法と見なされます。
トーマスオーエンズ

2
@ThomasOwens:それは「良いソフトウェア開発」のように聞こえます。例外が通常発生する前に失敗する多数のIFステートメント(またはアサーション)を記述する口実として使用される防御的なプログラミングを見たことがあります。本当に良いアイデアの長いリストを「防御的プログラミング」とは呼びません。良いアイデアのリストを「プログラミング」と呼びます。そのようにして、リストされているすべてのスマートなものから時間の浪費を分離できます。
S.Lott

2
私は自分でこれらの「コードを書くときの良いアイデア」と呼ぶことを好みますが、防御的プログラミングについて教えられたとき、システムの安全性、セキュリティ、および信頼性を確保するという明確な目的を持つあらゆる技術を指すと教えられました。たぶんそれは過度に広い定義か、間違った定義かもしれませんが、それは私が教えられたものです。if文やアサーションを「防御的プログラミング」と呼ぶ人を見てきましたが、教えられた定義に基づいて、そういうものとは呼びません(例外など、必ずしもより良いオプションがない場合を除きます)。
トーマスオーエンズ

@ThomasOwens:「たぶんそれは広すぎる定義です」。同意する。良いアイデアの素晴らしいチェックリストのようです。
S.Lott

2
-1:DbCがどのように防御的にプログラムする方法であるかわかりませんが、基本的に反対です。時間を浪費するためだけに防御的なプログラミングを行うことはよくあることだと思います。また、「エラーを追加することが示される可能性がある」場合、それはまったく明らかではないため、引用が必要です。
マーク
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.