タグ付けされた質問 「design-by-contract」

私は最近、Design by Contract（DbC）を発見しましたが、コードを記述する非常に興味深い方法であることがわかりました。とりわけ、それは提供するように思われるでしょう： より良いドキュメント。契約は文書であるため、契約が期限切れになることは不可能です。また、コントラクトはルーチンの動作を正確に指定するため、再利用のサポートに役立ちます。 簡単なデバッグ。プログラムの実行はコントラクトが失敗した瞬間に停止するため、エラーは伝播できず、違反した特定のアサーションが強調表示されると考えられます。これにより、開発時およびメンテナンス時にサポートが提供されます。 より良い静的分析。DbCは基本的にHoareロジックの単なる実装であり、同じ原則を適用する必要があります。 それに比べて、コストはかなり小さいようです。 余分な指タイプ。契約書を綴る必要があるため。 契約書の作成に慣れるには、ある程度のトレーニングが必要です。 現在、主にPythonに精通しているため、実際には前提条件（不適切な入力に対して例外をスローするだけ）を作成することが可能であり、特定の事後条件を再度テストするためにアサーションを使用することもできます。しかし、「古い」または「結果」などの特定の機能をシミュレートすることは、最終的に非Pythonicと見なされる余分な魔法なしでは不可能です。（さらに、サポートを提供するライブラリがいくつかありますが、ほとんどの開発者がそうではないように、最終的にはそれらを使用するのは間違っているでしょう。）それは他のすべての言語でも同様の問題だと思います（もちろん、エッフェル）。 私の直感では、サポートの欠如はある種の慣行に対する拒絶の結果であるに違いないが、オンラインでの検索は有益ではなかったと教えてくれます。ほとんどの現代言語がほとんどサポートを提供していないように見える理由を誰かが明確にできるかどうか疑問に思っていますか？DbCに欠陥があるか、過度に高価ですか？それとも、エクストリームプログラミングやその他の方法論のために時代遅れになっているのでしょうか？

40 language-design  design-by-contract 

私は、クライアントが設計上の契約の最後に留まっていることを保証する目的で、入力を検証するためのランタイムチェックを行うかどうかという質問に対する確かな答えを見つけたいと思っていました。たとえば、単純なクラスコンストラクターを考えます。 class Foo { public: Foo( BarHandle bar ) { FooHandle handle = GetFooHandle( bar ); if( handle == NULL ) { throw std::exception( "invalid FooHandle" ); } } }; この場合、ユーザーはFoo有効ななしでを作成しようとするべきではないと主張しますBarHandle。がコンストラクタのbar内部で有効であることを確認するのは適切ではないようですFoo。そのFooコンストラクタに有効な が必要なことを単純に文書化した場合BarHandle、それで十分ではありませんか？これは、契約による設計の前提条件を強制する適切な方法ですか？ これまでのところ、私が読んだことはすべて、これについてさまざまな意見があります。50％の人がそれbarが有効であることを確認すると言うようですが、他の50％は私がそれをすべきではないと言っています。たとえば、ユーザーBarHandleが正しいことを確認したが、2番目の（そして不要な）チェックを行う場合を考えてください。もFooコンストラクタの内部で行われています。

8 c++  design  interfaces  design-by-contract