問題タブ [code-contracts]

わかりました、これは少しハックかもしれませんが、我慢してください:)背景は、そのifステートメントがメソッド全体のインデントを台無しにするメソッドにうんざりしていることです。

だから私は考えていたのですが、代わりに次のようなことができればいいのではないでしょうか:

このケースは、何らかの形でコード コントラクトによってカバーされる可能性があります。その場合は、私を修正してください :)

ステートメントが true に評価されない場合、null が返されるという考え方です。メソッドの戻り値の型がない場合は、次のようになります: Require(IsOpenFilter(inputStr));

2つの質問があると思いますが、これはどうにかして行うことができますか? メソッドの呼び出しから条件付きリターンを行う方法に困惑しています。

他の質問は、これは良い考えですか? このように言語にモンキー パッチを適用するのは少し奇妙ですが、コードの読み取り方が好きです。メソッドの上の属性に入れることができれば、さらにきれいになります: [Require(IsOpenFilter(inputStr))]

.NET 4 では、新しい機能としてコード コントラクトが導入されました。CC を使用したいのですが、3.5 SP1 でも実行できるファイルを提供してください。それは可能ですか？新機能の一部のみを使用することはできますか? 明らかに、バイナリ ファイルに含めずに静的チェックのみを行う CC を設定することは可能ですが、それは正しいですか?

CC が 3.5 用に個別のモジュールとして利用可能だったことは承知していますが、CC の 4 バージョンを使用できない場合、これは実行可能な回避策ですか? 機能セットに違いはありますか?

私はクラス ライブラリを作成しており、その一部は世界中の他のユーザーによって使用されています。Visual Studio 2010 を使い始めた今、通常の古いものではなく、コード コントラクトを使用することに切り替えるのがどれほど良い考えなのか疑問に思っています。スタイルifステートメント。

すなわち。これの代わりに：

これを使って：

私が質問している理由は、静的チェッカーを使用できないことを知っているためです。そのため、コンパイラーが検証できないいくつかの仮定について少し神経質になっています。これにより、静的チェッカーを使用している場合に、クラス ライブラリをダウンロードしてもコンパイルされない可能性があります。これは、問題を再現することさえできないという事実と相まって、修正するのが面倒になります。箱。

だから私はいくつかの質問があります：

• アクセスできる場合、静的チェッカーはデフォルトでオンになっていますか? または、クラス ライブラリでオンにする必要がある設定がありますか (静的チェッカーがないため、しません)。
• 私の恐れは不当ですか？上記のシナリオは実際の問題ですか?

どんなアドバイスでも大歓迎です。

編集：私が何を意味するのかを明確にしましょう。

クラスに次のメソッドがあるとします。

そして、私はこのコードを持っています:

さて、ここで IoC が起動し、いくつかの「ランダムな」クラスを解決して、ファイル名を提供します。このライブラリの場合、null 以外のファイル名を返さないクラスを取得する方法はありませんが、IoC 呼び出しの性質上、静的分析ではこれを確認できません。 、したがって、可能な値がnullである可能性があると想定する場合があります。

したがって、静的分析では、LogToFileメソッドが引数で呼び出されるリスクがあり、nullビルドに失敗すると結論付ける場合があります。

コードに仮定を追加できることは理解しています。コンパイラは、fileNameそのメソッドから返される値が決してnullにならないことを前提としてそれを取るべきだと言っていますが、静的アナライザー（VS2010 Professional）がない場合は、上記のコードは私のためにコンパイルされるので、Ultimate を使用している誰かが見つけられるように、これを眠っているバグとして残しておくかもしれません。つまり、ここに問題がある可能性があるというコンパイル時の警告がないため、ライブラリをそのままリリースする可能性があります。

それで、これは本当のシナリオと問題ですか？

System.Diagnostics.Contracts.ContractExceptionは、私のテストプロジェクトではアクセスできません。このコードは、純粋に私自身がVisual Studioの光沢のある新しいコピーをいじっていることに注意してください。しかし、私が間違っていることを知りたいのです。

VSのプロフェッショナル版を使用しているため、静的チェックはありません。（私が好きな）コードコントラクトを引き続き使用するために、私のメソッドが機能する唯一の方法は、実行時にスローされる例外をキャッチすることであると考えましたが、これが可能であるとは思いません。

試験方法

方法

エラー

編集

もう少し考えた後、私はコメントと以下で議論された結論に達しました。方法を考えると、これがコードコントラクトフォームで表現できる要件がある場合は、そのようにテストを記述します。

これにより、コントラクトがコードの一部であり、削除されないことが保証されます。ただし、これには、コードコントラクトが指定された例外を実際にスローする必要があります。ただし、これが必要ない場合もあります。

この説明では、オブジェクト コンストラクターが受け取るパラメーターには、状態依存性とサービス依存性の 2 種類があります。IOC コンテナーを使用してサービスの依存関係を提供するのは簡単です。DI が引き継ぎます。しかし対照的に、状態の依存関係は通常、クライアントだけが知っています。つまり、オブジェクト リクエスタです。

クライアントが IOC コンテナーを介して状態パラメーターを提供することは、非常に苦痛であることが判明しました。これを行うためのいくつかの異なる方法を示しますが、そのすべてに大きな問題があり、私が見逃している別のオプションがないかコミュニティに尋ねます。さぁ、始めよう：

プロジェクト コードに IOC コンテナーを追加する前に、次のようなクラスから始めました。

Logger サービスの依存関係を Foobar クラスに追加することにしました。これは、おそらく DI を通じて提供します。

しかし、クラス Foobar 自体を「スワップ可能」にする必要があるとも言われました。つまり、Foobar インスタンスをサービス検索する必要があります。ミックスに新しいインターフェイスを追加します。

サービス ロケーターを呼び出すと、ILogger サービスの依存関係が DI されます。残念ながら、状態の依存関係である Alpha と Omega については、同じことが当てはまりません。一部のコンテナーでは、これに対処するための構文が提供されています。

この機能は気に入っていますが、型が指定されておらず、(インテリセンスなどを介して) どのパラメーターを渡さなければならないかが開発者に明らかでない点が気に入りません。だから私は別の解決策を見ます：

上記は型安全性とインテリセンスの問題を解決しますが、(1) クラス Foobar に DI ではなくサービスロケーターを介して ILogger をフェッチするように強制し、(2) 一連のボイラープレート (XXXFactory、IXXXFactory) を作成する必要があります。私が使用する可能性のあるすべての種類の Foobar 実装について。純粋なサービス ロケーター アプローチを使用することに決めたとしても、問題にはならないかもしれません。しかし、これを機能させるために必要なボイラープレートのすべてにまだ耐えられません。

そこで、コンテナーが提供するサポートの別のバリエーションを試します。

このアプローチにより、私は自分のインテリセンスを半分回復しました。しかし、「FoobarParams」パラメーターの指定を忘れた可能性があるエラーを検出するには、実行時まで待たなければなりません。

それでは、新しいアプローチを試してみましょう。

具体的な「Foobar」クラスを使用して IFoobar を作成していることは、実際には気にしません。これは、私のコードで変更する予定のない基本概念を表しています。カプセル化されているため、静的な「Create」に型安全性がないことも気にしません。私のインテリセンスも機能しています！この方法で作成された具体的なインスタンスは、指定された状態パラメーターが適用されない場合は無視されます (Unity 2.0 の動作)。おそらく、別の具象実装「FooFoobar」には正式な引数名の不一致がある可能性がありますが、それでもかなり満足しています。

しかし、このアプローチの大きな問題は、Unity 2.0 でのみ効果的に機能することです (構造マップのパラメーターが一致しないと例外がスローされます)。だから、Unity と一緒にいるだけでいいのです。問題は、Structure Map がますます好きになり始めていることです。だから今、私はさらに別のオプションに行きます:

これで、他のアプローチとの妥協点がいくらか得られました: (1) 私の引数はタイプ セーフ/インテリセンス対応です (2) ILogger を DI (上に表示) またはサービス ロケーター ( 3) 1 つまたは複数の別個の具体的な FoobarFactory クラスを作成する必要はありません (前述の冗長な「ボイラープレート」の例のコードとは対照的です)。(4) 「インターフェースを正しく使いやすく、使いにくくする」という原則を合理的に支持します。使い方を間違えます。」少なくとも、これまでに説明した代替案よりも悪くないことはほぼ間違いありません。

受け入れの壁はまだ1つ残っています。「デザイン・バイ・コントラクト」も適用したいのです。

私が提示したすべてのサンプルは、最も一般的に実践されている「不変」サポートを維持したいため、意図的にコンストラクター注入 (状態の依存関係) を優先していました。つまり、コンストラクターが完了すると、不変条件が確立されます。

上記のサンプルでは、​​オブジェクトの構築が完了すると、不変条件は確立されません。私が自家製の「契約による設計」を行っている限り、 Initialize(...) メソッドが呼び出されるまで不変式をテストしないように開発者に伝えることができます。

しかし、もっと要点を言えば、.net 4.0 が出てきたら、その「コード コントラクト」サポートをコントラクトによる設計に使用したいと考えています。私が読んだことから、この最後のアプローチとは互換性がありません。

呪い！

もちろん、私の哲学全体がずれていることにも気付きます。おそらく、サービスロケーターを介して Foobar : IFoobar を呼び出すことは、それがサービスであることを意味し、サービスには他のサービスの依存関係のみがあり、状態の依存関係はありません (これらの例のアルファやオメガなど)。私はそのような哲学的な問題にも耳を傾けますが、その思考の道に私を導く、どの半権威的な参考文献を読むべきかを知りたい.

だから今、私はそれをコミュニティに向けます。まだ検討していないアプローチは何ですか？自分の選択肢を使い果たしたと本当に信じなければなりませんか?

ps この種の問題は、他の問題とともに、少なくとも .net における IOC コンテナーのアイデア全体が時期尚早であると私に信じさせます。「C」言語をオブジェクト指向に感じさせるために頭を抱えていた時代を思い出します (変なマクロを追加するなど)。私たちが探しているのは、CLR と IOC コンテナーの言語サポートです。たとえば、「開始」と呼ばれる新しい種類のインターフェースを想像してみてください。初期化はインターフェイスのように機能しますが、特定のコンストラクター シグネチャも必要です。残りは生徒の練習として残します...

CodeContracts 静的解析ツールと議論しています。

私のコード:

(アスキー版)

ツールはinstance.bar、null 参照である可能性があることを示しています。私は反対のことを信じています。

誰が正しいですか？どうすればそれが間違っていると証明できますか?

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

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

C# 4.0 で Code Contracts を使用しています。オプションのパラメーターをシミュレートするために、通常の静的メソッド チェーンを適用しています (C# 4.0 がオプションのパラメーターをサポートしていることは知っていますが、実際には使用したくありません)。

問題は、メソッドを呼び出すと、コントラクト要件が 2 回 (または、実装する連鎖オーバーロードの数) 実行されることです。これはInit(string , string[])、以下のサンプル ソース コードから明らかな効果です。これは、特に私が使用するような比較的高価な要件のために、高価になる可能性がありFile.Existsます。

ただし、そのメソッドから要件を削除すると、静的チェッカーはオーバーロードの要件が満たされInit(string, string[], string)ていないと不平を言います。静的チェッカーは、Init(string, string[], string)オーバーロードの要件が暗黙的にInit(string, string[])メソッドにも適用されることを理解していないと思います。コード IMO から完全に控除できるもの。

これは私が達成したい状況です:

Init(string, string[], string)だから、私の質問はこれです:暗黙的にInit(string, string[])自動的に適用される要件を持つ方法はありますか?

アップデート

メソッドを間違った方法で使用してForAllいました。次のように、要件内などで使用することを目的としています。

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

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

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

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

ありがとう

単体テストを備えた C# のビジネス アプリがあります。NModel または Spec Explorer を使用して、信頼性を高め、テストの時間と費用を削減できますか? あるいは、F# (または Haskell) で書き直した場合、どのような種類の信頼性が (もしあれば) 向上するでしょうか?

コード契約？ASML?

これは主観的であり、おそらく議論の余地があることを認識しているため、可能であれば回答をデータでバックアップしてください. :) それとも、Eric Evans Cargo Shipping System のような実用的な例でしょうか?

考えると

単体テストは具体的で強力な定理であり、特定の「興味深いインスタンス」で準静的にチェックされ、型は一般的だが弱い定理 (通常は静的にチェックされる) であり、契約は一般的で強力な定理であり、実行中に発生する特定のインスタンスを動的にチェックします。通常のプログラム操作。(B. ピアースの「有害と見なされるタイプ」から)、

これらの他のツールはどこに適合しますか?

Java PathFinder、Scala などを使用して、Java について同様の質問をすることができます。