契約による設計のベストプラクティスは何ですか

Question

契約による設計のベストプラクティスは何ですか？

1）総プログラミング：大学

は、私たちは問題に取り組むには3つの方法を学んだ（OO環境での）契約paradigma によってデザインを学んだその 効果ですべての可能な例外的なケースをカバー（参照：数学）

2）公称プログラミング：のみ「約束」前提条件が満たされている右の効果。 ）

3（そうでなければ効果は未定義である）守備プログラミング：方法今

の違法な呼び出しを知らせるために、例外を使用して、我々はそれぞれの状況での正しい使用上の異なるOOのシナリオに焦点を当ててきたが、我々は学んでいません誰が使用するのか...

私は先生に尋ねていないことが非常に奇妙だと思います（しかし、再度、講義中、誰も持っていません）

は個人的に、私は決して今名目を使用していない、と前提条件を交換する傾向があります（つまり、私はむしろIllegalDivisionByZeroを使用して、 'precondition：dividerは0と異なるはずです）、プログラム全体が意味をなさない（私は除算で従来の値を0に戻しません）。ちょうど個人的な発見や好きに基づいています。

ので、私は君たちを求めています：

は、任意のベストプラクティスはあります？

Answer 1

私はこの部門について知らなかったし、実際に私の経験を反映していません。

合計プログラミングは事実上不可能です。すべての例外的なケースをカバーする保証はありません。だから、基本的に、あなたの範囲を限定し、範囲外である状況を拒否すべきである（つまり、事前条件の役割だ）

公称プログラミングが望まれていません。未定義の効果は禁止されるべきです。

防御プログラミングは必須です。メソッドの不正な呼び出しを常に通知する必要があります。

私は私の意見では、総プログラミング

前提条件（一種のの実用的かつaffortableバージョンで完全なデザイン・バイ・契約の要素の実装、賛成によDefensive Programming）を使用して、メソッドの不正な呼び出しを通知します。可能な限りスコープを制限して、コードを単純化できるようにしてください。可能であれば、範囲を少し狭めることによって、複雑な実装を避けてください。

ポストコンディション希望の効果が得られない場合はエラーを発生させます。あなたのせいであっても、あなたの目標を逃したことを発信者に知らせるべきです。

不変式オブジェクトの一貫性が保持されていることを確認します。

Answer 2

それはすべての責任はあなたがクライアントとの契約の実装に割り当てる何に沸きます。

は防御的プログラミングでは、いくつかのケースでcosty、あるいは不可能であるエラー条件をチェックするために実装を強制します。 binarySearchで指定された契約を想像してみてください。たとえば、入力配列をソートする必要があります。アルゴリズムを実行中はこれを検出できません。実行時間を実際に突き合わせる手動チェックが必要です。私の意見を裏付けるために、javadocsからの方法の署名です。もう一つのポイントは、人々とフレームワークである

は今、間違って何かが起こる場合だけでポップアップ表示されます例外を実行時にチェック例外（守備のスタイル）を変換するために主に使用された例外の変換メカニズムを実装する傾向があります。この方法では、契約のクライアントと実装者はお互いに対処しながら心配することが少なくなります。

ここでも、これは私の個人的な意見ですが、私が持っている経験を制限するものでのみ裏打ちされた、私はこの主題についての詳細を聞いてみたいです。

Answer 3

...しかし はWHICHを使用するときに我々は学んでいない...

私は、ベストプラクティスは、「可能な限り守備のよう」であることをだと思います。可能であれば、ランタイムチェックを行います。 @MahdeToが時々言及したように、パフォーマンスの理由から不可能です。そのような場合は未定義または不満足な振る舞いに落ちる。

これは、ランタイムチェックの対象となるものとそうでないものとを明示的に文書化したものです。

Answer 4

多くの場合、「それは依存している」という計算は、おそらく最良の答えです。

契約による契約/プログラミングによる設計は、機能の条件を明示的に文書化することによって開発を大きく助けることができます。ドキュメントだけで、（コンパイルされた）コードにしなくても助けになることができます。

実現可能な場合は、すべての条件を守ることをお勧めします。ただし、開発およびデバッグビルドの場合にのみ使用します。このようにして、条件が崩れた場合、最も無効な仮定が捕捉されます。優れたビルドシステムを使用すると、モジュールやファイルレベルで、またグローバルにさまざまな条件タイプをオン/オフすることができます。

リリースバージョンのソフトウェアで実行されるアクションは、システムおよび条件の起動方法（通常は外部インターフェイスと内部インターフェイスの区別）によって異なります。リリースのバージョンは「トータルプログラミング」になる可能性があります。すべての条件で定義された結果が返されます（エラーまたはNaNが含まれます）。

私にとって、「公称プログラミング」は現実世界では行き止まりです。適切な値を渡した場合（当然のことながら）、受信した値が良好であると仮定します。あなたの前提が間違っていれば、あなたは崩壊します。

Answer 5

私はテスト駆動型プログラミングが答えだと思います。モジュールを実際に実装する前に、まず単体テスト（契約と呼ぶ）を作成します。その後、徐々に機能を実装し、契約が有効であることを確認してください。通常、私は普通のスタブとモックアップで始まり、徐々にスタブを本物のものに置き換えます。改善を続け、テストをより強くする。最後に、上記のモジュールの堅牢な実装と、テストベッドでコード化された契約の実装が完成しました。後で、誰かがモジュールを変更した場合は、最初にテストベッドに適合するかどうかを確認します。そうでない場合は、契約が破られている - 変更を拒否します。または、契約が古くなっている - ユニットテストを修正する。それでは..ソフトウェア開発の退屈なサイクル:)