問題タブ [design-by-contract]

Java Assert を使用している開発者はあまり見かけませんが、私は非常に熱心に使用しています。それらを効果的に使用するためのヒントを教えてください。

額面どおり、オブジェクト初期化子は .net 4.0 の「コード コントラクト」に問題をもたらすように思われます。通常は、オブジェクト コンストラクターが終了するまでに不変条件を確立する必要があります。ただし、おそらく、オブジェクト初期化子では、構築が完了した後にプロパティを設定する必要があります。

私の質問は、コンストラクターが完了する前にプロパティが設定されたかのように、「コード コントラクト」の不変条件がオブジェクト初期化子を処理できるかどうかです。それは確かにとてもいいでしょう！

質問をざっと見て、私は最近assertJavaでキーワードを発見しました。最初はワクワクしていました。まだ知らなかった便利なもの！入力パラメータの有効性をチェックするためのより効率的な方法！イェーイ学習！

しかし、それから私は詳しく調べました。私の熱意は、1つの単純な事実によって、「完全に消し去られる」ほど「和らげられる」ことはありませんでした。アサーションをオフにすることができます。*

これは悪夢のように聞こえます。listOfStuff入力がである場合にコードを続行したくないと主張している場合、null一体なぜその主張を無視したいのでしょうか。プロダクションコードの一部をデバッグしlistOfStuffていて、誤って渡された可能性があるがnull、そのアサーションがトリガーされたというログファイルの証拠が見当たらない場合は、listOfStuff実際に有効な値が送信されたとは信じられません。また、アサーションが完全にオフになっている可能性についても説明する必要があります。

そして、これは私がコードをデバッグしていることを前提としています。アサーションに慣れていない人は、それを見て、（かなり合理的に）アサーションメッセージがログに表示されlistOfStuffない場合は問題ではないと想定する可能性があります。あなたの最初の出会いがassert野生であった場合、それが完全にオフにされる可能性があることさえあなたに起こりますか？結局のところ、try/catchブロックを無効にできるコマンドラインオプションがあるわけではありません。

そのすべてが私の質問に私をもたらします（そしてこれは質問であり、暴言の言い訳ではありません！私は約束します！）：

私は何が欠けていますか？

assertJavaの実装を、私が認めているよりもはるかに便利にするニュアンスはありますか？コマンドラインから有効/無効にする機能は、実際にはいくつかのコンテキストで非常に価値がありますか？次のようなステートメントの代わりに本番コードで使用することを想定している場合、私はそれをどういうわけか誤解していif (listOfStuff == null) barf();ますか？

私はここで私が得ていない重要な何かがあるように感じます。

*技術的に言えば、実際にはデフォルトでオフになっています。それらをオンにするには、邪魔にならないようにする必要があります。しかし、それでも、それらを完全にノックアウトすることができます。

何よりもまずデバッグツールであるという概念assertは、私にとって意味のあるものにするために非常に長い道のりを歩んでいます。

開発者は悪い入力は不可能だと考えているため、本番環境では重要なプライベートメソッドの入力チェックを無効にする必要があるという考えにまだ問題があります。私の経験では、成熟したプロダクションコードは、さまざまな程度の正気度の急速に変化する要件を対象としたさまざまな程度のスキルを持つ人々によって何年にもわたって開発された、狂った、広大なものです。そして、悪い入力が本当に不可能であるとしても、今から6か月後のずさんなメンテナンスコーディングの一部がそれを変える可能性があります。 提供されているリンクgustafc（ありがとう！）には、例としてこれが含まれています。

assert interval > 0 && interval <= 1000/MAX_REFRESH_RATE : interval;

本番環境でこのような単純なチェックを無効にすると、ばかげて楽観的になります。ただし、これはコーディング哲学の違いであり、壊れた機能ではありません。

さらに、私は間違いなくこのようなものの価値を見ることができます：

assert reallyExpensiveSanityCheck(someObject) : someObject;

この機能を理解するのを手伝ってくれたすべての人に感謝します。大変感謝しております。

私は学校の目的で独自の ArrayList を実装していますが、少し刺激を与えるために、C# 4.0 コード コントラクトを使用しようとしています。コンストラクターにコントラクトを追加する必要があるまでは、すべて問題ありませんでした。空のパラメーター コンストラクターに Contract.Ensures() を追加する必要がありますか?

はい、各メソッドには明確に定義されたコントラクトが必要です。一方、「メイン」コンストラクターに作業を委譲するだけなら、なぜそれを置くのでしょうか? 論理的には、その必要はありません。

両方のコンストラクターでコントラクトを明示的に定義することが役立つと思われる唯一のポイントは、将来、コントラクトの Intelisense サポートがあるかどうかです。その場合、Intelisense で表示されるように、各メソッドが持つコントラクトを明示すると便利です。

また、Design by Contracts の原則と使用法についてもう少し詳しく説明している本はありますか? 1 つのことは、言語 (この場合は C#) でコントラクトを使用する方法の構文に関する知識を持っていることであり、もう 1 つはそれをいつどのように使用するかを知っていることです。いくつかのチュートリアルと、それに関する Jon Skeet の C# in Depth の記事を読みましたが、可能であればもう少し深く掘り下げたいと思います。

ありがとう

次のロジックのコードが少しあります。

理論的には、常に1つの要素が存在するため、この方法では問題は発生しません。いずれにせよ、念のため、メソッドの最後にアサーションを付けました。

問題は、このメソッドが何かを返す必要があり、コンパイラがアサーションがプログラムの実行を中断することを理解していないことです。コントラクトを使用する前は、このような状況で、問題を解決するために例外をスローしていました。これをContract.Assert（）でどのように処理しますか？Contract.Assert（）呼び出しの後にnullまたはdefault（element_type）を返し、それが呼び出されないことを認識してコンパイラーをシャットダウンしますか？または、これを行う他のよりエレガントな方法はありますか？

ありがとう

契約によるコーディングに飛び込みたい。VS2010 (C# 4.0 コンパイラを使用) を入手しましたが、3.5 フレームワークをターゲットにする必要があります。

.NET 4.0 に最も似たクラスとインターフェイスを備えたコントラクト ライブラリによるサード パーティ コードはどれですか?

最近では、大学での OS プログラミング コースから習慣を得て以来、すべての関数のすべての前提条件をチェックすることに慣れています。

一方、ソフトウェア工学コースでは、共通の前提条件は 1 回だけチェックするように教えられました。たとえば、関数が別の関数に委譲されている場合、最初の関数はそれらをチェックし、2 つ目の関数では再度チェックする必要があります。冗長です。

冗長な点は確かにわかりますが、常にチェックする方が安全だと思います。さらに、以前にチェックした場所を追跡する必要はありません。

ここでのベストプラクティスは何ですか?

最近、ユニットテストについて同僚と興味深い議論をしました。契約が変更されたときに、単体テストの保守の生産性が低下したときについて話し合っていました。

おそらく、誰でもこの問題に取り組む方法を教えてくれるでしょう。詳しく説明しましょう：

ですから、気の利いた計算を行うクラスがあるとしましょう。コントラクトは、数値を計算する必要があると述べています。または、何らかの理由で失敗した場合は -1 を返します。

私はそれをテストする契約テストを持っています。そして、他のすべてのテストでは、この気の利いた電卓をスタブします。

したがって、契約を変更すると、計算できないときはいつでも CannotCalculateException がスローされます。

私の契約テストは失敗するので、それに応じて修正します。ただし、モック/スタブ化されたすべてのオブジェクトは、古いコントラクト ルールを引き続き使用します。これらのテストは成功しますが、成功するはずはありません!

ここで問題になるのは、単体テストに対するこの信頼を基に、そのような変更をどれだけ信頼できるかということです... 単体テストは成功しますが、アプリケーションのテスト中にバグが発生します。この計算機を使用するテストは修正する必要があります。これには時間がかかり、何度もスタブ/モックされることさえあります...

このケースについてどう思いますか？私はそれについて深く考えたことはありませんでした。私の意見では、単体テストに対するこれらの変更は受け入れられるでしょう。単体テストを使用しないと、テスト段階で (テスターに​​よって) そのようなバグが発生することもわかります。しかし、何がより多くの時間 (またはより短い時間) を要するかを指摘できるほど自信がありません。

何かご意見は？

この不変のタイプを考えてみましょう。

ここで注意すべき2つのこと：

• Pathプロパティが決してすることができないことを保証する契約不変量がありますnull
• pathコンストラクターは、引数の値をチェックして、前のコントラクト不変条件を尊重します

この時点で、Settingインスタンスがnull Pathプロパティを持つことはできません。

ここで、このタイプを見てください。

_path基本的に、静的チェック中に満たすことができない独自のコントラクト不変量（フィールド上）があります（上記のコメントを参照）。それを証明するのは簡単なので、それは私には少し奇妙に聞こえます：

• settings不変です
• settings.Pathnullにすることはできません（設定には対応するコントラクトが不変であるため）
• したがって、に割り当てることによりsettings.Path、_pathnullに_pathすることはできません

私はここで何かを逃しましたか？

.NET 4 を使用した C# の個人プロジェクトで、契約による設計の使用を検討しています。

契約フレームワークによる設計でのMicrosoftの試みについて読んでいます： http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx

しかし、多くの選択肢があり、私は困惑しています。それぞれの長所と短所は何ですか？