問題タブ [design-by-contract]

asp.netのMicrosoft.Contracts名前空間が必要なのは何ですか?

つまり、どのような場合に書くことができますusing Microsoft.Contracts;か?

この目標を達成するための一般的な方法は次のとおりです。

この解決策は醜いと思います。メソッドは、有効な入力パラメータコントラクトをチェックするボイラープレートコードですぐにいっぱいになり、メソッドの核心を覆い隠します。

これが私が欲しいものです：

それらのアノテーションがJSR303/ Bean Validation Specのように見える場合、それは私がそれらを借りたためです。残念ながら、これらはこのようには機能しないようです。これらは、インスタンス変数に注釈を付けてから、バリデーターを介してオブジェクトを実行することを目的としています。

多くのJavaの契約による設計フレームワークのうち、私の「欲しい」例に最も近い機能を提供するのはどれですか？スローされる例外は、カプセル化が壊れないように、実行時例外（IllegalArgumentExceptionsなど）である必要があります。

私が最もよく知っているのはLispバリアント（ClojureまたはSchemeのボーナスポイント）の例であることが望ましいですが、機能言語でのDBCに関するフィードバックは、もちろん、より大きなコミュニティにとって価値があります。

明らかな方法は次のとおりです。

この実装について私が気に入らないのは、コントラクトロジックがコア機能を覆い隠していることです。関数の真の目的は、条件付きチェックで失われます。これは、この質問で提起したのと同じ問題です。Javaのような命令型言語では、ドキュメントに埋め込まれたアノテーションまたはメタデータ/属性を使用して、メソッドの実装からコントラクトを移動できます。

Clojureのメタデータにコントラクトを追加することを検討した人はいますか？高階関数はどのように使用されますか？他にどのようなオプションがありますか？

dbc（http://en.wikipedia.org/wiki/Design_by_contract）について読んでいます。継承に関連してクラ​​ス不変条件を使用する簡単な例を教えてください。

契約による設計の投稿や例を読んでいますが、頭を包み込めないように見えるものがあります。私が見たすべての例で、DbC は事後条件 (多数の銀行口座など) で独自の状態をテストする単純なクラスで使用されます。

ほとんどの場合、クラスのメソッドを呼び出すと、メソッド呼び出しをその外部依存関係に委譲することで、はるかに多くの作業が行われるように思えます。メソッドの外部動作に焦点を当てた依存関係の反転とモック オブジェクトを使用して、特定のシナリオで単体テストでこれを確認する方法を理解していますが、これは DbC と事後条件でどのように機能しますか?

2 番目の質問は、複雑な事後条件の理解に対処する必要があります。多くの関数の事後条件を書き出すには、基本的に事後条件の関数の本体を書き直して、新しい状態がどうなるかを知る必要があるように思えます。そのポイントは何ですか？

私は DbC の概念が本当に気に入っています。特に、検証済みのコントラクトを見つけたときに障害状態を再現する方法を見つけられる場合は、大きな可能性があると思います。過去数時間にわたって、私はいくつかのきちんとしたものを読んでいます。Eiffel での自動テスト生成。私は現在、C++ 開発のプロセスを改善しようとしていますが、現在のプロジェクトで築いたすべての土台を失わないようにする方法を理解できれば、何か新しいことを学ぶことにオープンです。ありがとう。

私が達成したいことをコード例で示すのが最善ですか?

(もちろん、渡された文字列はContract.Ensures()、実際の事後条件式の単なるプレースホルダーです。)

これどうやってするの？ここで役に立ちContract.OldValue<>()ますか？

クライアントが Entity Framework を使用しているプロジェクトがあり、生成されたクラスを残りのアプリケーションから抽象化しようとしています。

生成されたクラスの 1 つは Category で、Type というプロパティがあります。

次のように、Category に実装するインターフェイスを作成しました。

以前に LINQ to SQL でこれを行ったことがありますが、問題なく動作します。別のファイルに部分クラスを作成し、インターフェイスを実装します。

ただし、EF を使用してクエリを作成しようとすると、OfType<>() をサポートしていないと表示されます。

例：

ここで何が間違っていますか？

その他の注意点: Silverlight アプリケーションでこれを開発しており、データ コンテキストは実際にはサービスから取得されているため、ここでもクライアントとサーバーの関係が進行しています。

非常に多くの場合hashcode()、equals()単に機能しない OO コードベースがあります。主な理由は次のとおりです。

オブジェクト指向の抽象化の利点を諦めない限り、インスタンス化可能なクラスを拡張して値コンポーネントを追加する方法はありません。

これは、Joshua Bloch による「Effective Java」からの引用であり、このテーマについては、次の Artima の優れた記事で詳しく説明しています。

http://www.artima.com/lejava/articles/equality.html

これは、この質問の目的ではありません。

問題は、場合によっては契約を満たすことができないという事実があることがわかった場合、UnsupportedOperationExceptionを自動的に作成してスローequals()するクリーンな方法は何でしょうか?hashcode()equals()

注釈は機能しますか? 私は次のようなことを考えています@NotNull:すべての@NotNull契約違反は自動的に例外をスローし、パラメータ/戻り値に注釈を付ける以外に何もする必要はありません@NotNull.

同じ検証/スロー例外コードを常に繰り返すのではなく、8 文字 ("@NotNull") であるため便利です。

私が懸念しているケースでhashCode()/equals()は、意味をなさないすべての実装で、常に同じことを繰り返しています。

ただし、これはエラーが発生しやすくなります。誤ってこれをカット/ペーストするのを忘れて、ユーザーがそのようなオブジェクトを誤用する可能性があります (たとえば、デフォルトの Java コレクションに入れようとするなど)。

または、この動作を作成するための注釈を作成できない場合、AOP は機能しますか?

興味深いことに、実際の問題は Java 階層の存在そのものでhashCode()ありequals()、Java 階層の最上位にあり、場合によっては意味がありません。では、この問題をきれいに処理するにはどうすればよいでしょうか。

C# のコード コントラクトとは対照的に、JML のコード コントラクトは、メソッドのヘッダーでコメントの形式で使用される単なるテキストです。では、アノテーションとして公開した方がよいのではないでしょうか? そうすれば、情報をコンパイルしても、コメントとは対照的に、消去される.classのメタデータに残ります。

何か不足していますか？

この説明では、オブジェクト コンストラクターが受け取るパラメーターには、状態依存性とサービス依存性の 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 コンテナーの言語サポートです。たとえば、「開始」と呼ばれる新しい種類のインターフェースを想像してみてください。初期化はインターフェイスのように機能しますが、特定のコンストラクター シグネチャも必要です。残りは生徒の練習として残します...