4

私は最近、契約による設計について考えていますが、.NETで値の事前条件と事後条件を主張するための最良の方法は何だと人々が考えているのでしょうか。つまり、メソッドに対する引数値を検証します。

Debug.Assertを推奨する人もいれば、ifステートメントの使用と例外のスローについて話す人もいます。それぞれの長所と短所は何ですか？

どのようなフレームワークをお勧めしますか？

4

5 に答える 5

3

最終的には、.NET 4.0 の出荷時にコード コントラクトを使用する予定です。ただし、現在の製品コードでは、「Guard」クラスと例外を生成する一般的な方法で大きな成功を収めています。

詳細については、これに関する私の投稿を参照してください。

于 2009-05-21T02:27:52.127 に答える
3

別のオプションはSpec#です。

Spec# は、オブジェクト指向言語 C# の拡張です。型システムを拡張して、null 以外の型とチェック済み例外を含めます。オブジェクトの不変条件だけでなく、事前条件と事後条件の形でメソッド コントラクトを提供します。

于 2008-10-01T05:36:37.743 に答える
1

アサートよりも例外を好むのは、そうであるはずなのにそうでない場合は、修正できるようにそれについて知りたいからです。また、デバッグ モードで得られるカバレッジは、実際の使用法やカバレッジにはほど遠いので、 Debug.Assert を使用しても十分ではありません。

アサートを使用すると、リリース コードが肥大化することはありませんが、デバッグ ビルドでこれらのコントラクトをキャッチした場合にのみ、これらのコントラクトが破られる時期と理由がわかります。

例外を使用すると、デバッグまたはリリースが発生するたびにコントラクトの違反を確認できますが、リリース ビルドにはより多くのチェックとコードが含まれることも意味します。

中間のアプローチを採用し、Trace を使用して、問題のデバッグに使用できる何らかのアプリケーション ログに対して事前および事後条件を追跡することができます。ただし、ユーザーが直面している問題を知るには、これらのログを収集する方法が必要です。これを例外と組み合わせて、より深刻な問題の例外を取得する可能性もあります。

しかし、私が見る方法は、契約が強制する価値がある場合、それが壊れたときに例外をスローする価値があるということです。ただし、それは意見と対象アプリケーションに多少依存していると思います。例外をスローする場合は、発生した例外が処理されないままになっているときにクラッシュ レポートを提供する何らかの形式のインシデント レポート システムが必要になるでしょう。

于 2008-09-30T22:48:58.893 に答える
1

http://conditions.codeplex.com/で流暢なフレームワークを見ることができます 。オープン ソースで無料です。

于 2011-02-01T00:57:31.573 に答える
0

Spec＃はそれを行う方法であり、C＃のスーパーセットです。これで、Spec＃の言語に依存しないバージョンである「コードコントラクト」ができたので、たとえば、VB.NETでコードコントラクトを作成できます。

于 2009-05-21T02:16:31.010 に答える