契約によるデザインを専門的に使用していますか？それはプロジェクトの最初からやらなければならないことですか、それともギアを変えてソフトウェア開発ライフサイクルに取り入れ始めることができますか？デザインアプローチの長所/短所は何だと思いますか？
大学院のコースで契約によるデザインのアプローチに出くわしました。アカデミックな設定では、それはかなり便利なテクニックのようでした。しかし、私は現在、Design by Contractを専門的に使用しておらず、それを使用している他の開発者も知りません。SOの群衆から実際の使用法について聞くのは良いことです。
あまりお勧めできません。次のように、インライン ドキュメント コントラクト仕様を使用するスイートがある場合は特に便利です。
// @returns null iff x = 0
public foo(int x) {
...
}
次のように、生成された単体テストに変換します。
public test_foo_returns_null_iff_x_equals_0() {
assertNull foo(0);
}
そうすれば、実行中のテストを実際に見ることができますが、テストは自動生成されます。ちなみに、生成されたテストはソース管理にチェックインするべきではありません。
相互に対話する必要があるアプリケーション間のインターフェースがある場合、契約による設計を本当に高く評価するようになります。
契約がなければ、この状況はすぐに責任テニスのゲームになります。チームは非難を繰り返しており、膨大な時間が無駄になっています。
契約があれば、責任は明らかです。
呼び出し元は前提条件を満たしましたか? そうでない場合は、クライアント チームが修正する必要があります。
有効なリクエストが与えられた場合、受信者は投稿条件を満たしましたか? そうでない場合は、サーバー チームが修正する必要があります。
双方が契約を順守したが、結果は満足のいくものではありませんでしたか? 契約が不十分であり、問題をエスカレーションする必要があります。
このためには、コントラクトをアサーションの形で実装する必要はありません。コントラクトが文書化され、すべての関係者によって同意されていることを確認する必要があるだけです。
フランククルーガーは書いています：
Gaius：Null Pointer例外はランタイムによって自動的にスローされますが、関数プロローグでそのようなものをテストするメリットはありません。
これに対して2つの応答があります。
ヌルは単なる例です。square（x）の場合、結果の平方根が（おおよそ）パラメーターの値であることをテストしたいと思います。セッターの場合、値が実際に変更されたことをテストしたいと思います。アトミック操作の場合、すべてのコンポーネント操作が成功したか、すべて失敗したかを確認したいと思います（実際には、成功を1回テストし、失敗をn回テストします）。弱い型の言語のファクトリメソッドの場合、正しい種類のオブジェクトが返されることを確認したいと思います。リストはどんどん増えていきます。基本的に、1行のコードでテストできるものはすべて、プロローグコメントのコードコントラクトの非常に良い候補です。
実行時例外が生成されるため、テストすべきではないことに同意しません。どちらかといえば、実行時例外を生成する可能性のあるものをテストする必要があります。ランタイム例外が好きなのは、システムが高速で失敗し、デバッグに役立つからです。しかし、nullこの例では、いくつかの可能な入力の結果値でした。二度と戻らないという議論がありnullますが、もしそうなら、それをテストするべきです。
STL、boost、MFC、ATL、および多くのオープン ソース プロジェクトを調べてみると、非常に多くの ASSERTION ステートメントがあり、それによってプロジェクトがより安全に進められることがわかります。
契約による設計！実際の製品で実際に機能します。
SOA 領域で何かを行うときに、契約に基づいて設計しないのは絶対にばかげています。特に、ブラック ボクセンが関与している場合に、ビットとピースが後で交換される可能性がある、あらゆる種類のモジュラー作業に取り組んでいる場合は、常に役に立ちます。 .
Go プログラミング言語には、コントラクトによる設計を可能にする構造がないことがわかります。パニック/遅延/回復は、遅延および回復ロジックがパニックを無視し、IOW が壊れたコントラクトを無視することを可能にするため、正確にはそうではありません。少なくとも必要なのは、なんらかの形の回復不能なパニックです。または、せいぜい、コントラクト コンストラクト (事前条件と事後条件、実装とクラスの不変条件) による設計の直接的な言語サポートです。しかし、Go船の実権を握っている言語純粋主義者の頭の固さを考えると、私はこれをほとんど変更しません.
パニック関数の最後の defer 関数で特別なアサート エラーをチェックし、runtime.Breakpoint() を呼び出して回復中にスタックをダンプすることで、アサートのような動作を実装できます。動作が条件付きである必要があることをアサートのようにします。もちろん、このアプローチは、アサートを行う関数の後に新しい遅延関数が追加されると崩壊します。これは、大規模なプロジェクトでは正確に間違ったタイミングで発生し、バグを見逃す結果となります。
私の要点は、 assert は非常に多くの点で役立つので、それを回避する必要があると頭痛の種になる可能性があるということです。
より表現力豊かなタイプのシステムの代わりに、ミリタリー グレードのプロジェクトでは契約による設計を絶対に使用します。
弱く型付けされた言語または動的スコープを持つ言語 (PHP、JavaScript) の場合、関数型コントラクトも非常に便利です。
他のすべてについては、ベータテスターと単体テストに依存することを脇に置きます.
Gaius : Null Pointer 例外は、ランタイムによって自動的にスローされます。関数のプロローグでそのようなものをテストするメリットはありません。ドキュメントにもっと興味がある場合は、静的アナライザーなどで使用できる注釈を使用します (たとえば、コードが注釈を壊していないことを確認するため)。
Design by Contract と組み合わせたより強力な型システムが進むべき道のようです。例としてSpec#を見てください。
Spec# プログラミング言語。Spec# は、オブジェクト指向言語 C# の拡張です。型システムを拡張して、null 以外の型とチェック済み例外を含めます。オブジェクトの不変条件だけでなく、事前条件と事後条件の形でメソッド コントラクトを提供します。
私の経験では、単体テストと契約による設計はどちらも価値のあるテスト手法です。
システム自動テスト フレームワークで契約による設計を使用してみましたが、私の経験では、単体テストでは簡単に得られない柔軟性と可能性が得られます。たとえば、より長いシーケンスを実行し、アクションが実行されるたびに応答時間が制限内であることを確認できます。
InfoQ でのプレゼンテーションを見ると、契約による設計は、コンポーネントの統合フェーズにおける従来の単体テストに追加する価値があるようです。たとえば、最初にモック インターフェイスを作成し、その後、またはコンポーネントの新しいバージョンがリリースされたときにコンポーネントを使用することができます。
.Net/Microsoft プラットフォームでの契約テストによる設計に必要なすべての設計要件をカバーするツールキットを見つけられませんでした。
はい、そうです！実は数年前、私は Argument Validation のための小さなフレームワークを設計しました。私は、さまざまなバックエンド システムがあらゆる種類の検証とチェックを行う SOA プロジェクトを行っていました。しかし、応答時間を増やすために (入力が無効な場合、およびそれらのバックエンド システムの負荷を減らすために)、提供されたサービスの入力パラメーターの検証を開始しました。Not Null だけでなく、String パターンにも使用できます。またはセット内の値。また、パラメーター間に依存関係がある場合もあります。
当時、契約フレームワークによる小さな設計を実装していたことに今気づきました:)
小さなJava Argument Validationフレームワークに興味のある方は、こちらのリンクを参照してください。これはプレーンな Java ソリューションとして実装されています。
私は実際には日常的に Design by Contract を使用していません。ただし、言語の一部としてD言語に組み込まれていることは知っています。