問題タブ [design-by-contract]

契約によるデザインを専門的に使用していますか？それはプロジェクトの最初からやらなければならないことですか、それともギアを変えてソフトウェア開発ライフサイクルに取り入れ始めることができますか？デザインアプローチの長所/短所は何だと思いますか？

大学院のコースで契約によるデザインのアプローチに出くわしました。アカデミックな設定では、それはかなり便利なテクニックのようでした。しかし、私は現在、Design by Contractを専門的に使用しておらず、それを使用している他の開発者も知りません。SOの群衆から実際の使用法について聞くのは良いことです。

API ドキュメント (「パブリック関数の javadoc」など) で、従来のドキュメントと同様に「値の制限」の説明をよく目にしますか?

注：コード内のコメントについて話しているのではありません

「値の制限」とは、次のことを意味します。

• パラメーターは null 値 (または空の文字列、または...) をサポートできますか?
• 「戻り値」はnullになる可能性がありますか、それともnullにならないことが保証されていますか（または「空」になる可能性がありますか...）？

サンプル：

私がよく目にするのは（ソースコードにアクセスできない場合）次のとおりです。

私が見たいのは次のとおりです。

私のポイントは次のとおりです。

getReaderNames() 関数を含むライブラリを使用する場合、多くの場合、その機能を推測するために API ドキュメントを読む必要さえありません。しかし、私はそれを使用する方法を確認する必要があります。

この関数を使用するときの私の唯一の懸念は、パラメーターと戻り値に関して何を期待する必要があるかということです。パラメータを安全に設定し、戻り値を安全にテストするために知っておく必要があるのはこれだけですが、API ドキュメントでそのような情報を目にすることはほとんどありません...

編集：

これは、チェックされた例外またはチェックされていない例外の使用に影響を与える可能性があります。

どう思いますか ？値制限とAPI、それらは一緒に属しますか?

契約によってプログラミングする場合、関数またはメソッドは、その責任に取り組み始める前に、その前提条件が満たされているかどうかを最初にチェックしますよね? これらのチェックを行う最も顕著な 2 つの方法は、 byassertと byexceptionです。

1. assert はデバッグ モードでのみ失敗します。個別のコントラクトのすべての前提条件を (ユニット) テストして、実際に失敗するかどうかを確認することが重要であることを確認します。
2. 例外は、デバッグおよびリリース モードで失敗します。これには、テスト済みのデバッグ動作がリリース動作と同じであるという利点がありますが、実行時のパフォーマンスが低下します。

どちらが好ましいと思いますか？

ここで関連する質問を参照してください

私は最近、契約による設計について考えていますが、.NETで値の事前条件と事後条件を主張するための最良の方法は何だと人々が考えているのでしょうか。つまり、メソッドに対する引数値を検証します。

Debug.Assertを推奨する人もいれば、ifステートメントの使用と例外のスローについて話す人もいます。それぞれの長所と短所は何ですか？

どのようなフレームワークをお勧めしますか？

Java のメソッド署名:

ルビーの同様のもの

Java の場合、型システムは、メソッドが何を期待し、何を提供するかについての情報を与えてくれます。Ruby の場合、何を渡すべきなのか、何を受け取ることになるのか、まったくわかりません。

Java では、オブジェクトは正式にインターフェースを実装する必要があります。Ruby では、渡されるオブジェクトは、ここで定義されたメソッドで呼び出されたメソッドに応答する必要があります。

これは非常に問題があるようです:

1. 100% 正確で最新のドキュメントがあっても、Ruby コードは本質的にその実装を公開し、カプセル化を破る必要があります。「OO の純度」はさておき、これはメンテナンスの悪夢のようです。
2. Ruby コードからは、何が返されているのかわかりません。基本的に実験するか、コードを読んで、返されたオブジェクトがどのメソッドに応答するかを調べる必要があります。

静的型付けとダック型付けについて議論するのではなく、契約によって設計する能力がほとんどない生産システムをどのように維持するかを理解しようとしています。

アップデート

このアプローチが必要とするドキュメントを介して、メソッドの内部実装の公開に実際に対処した人は誰もいません。インターフェースがないので、特定の型を想定していない場合、呼び出す可能性のあるすべてのメソッドを箇条書きにして、呼び出し元が何を渡すことができるかを知る必要はありませんか? それとも、これは実際には発生しない単なるエッジ ケースですか?

私は最新の C# アプリケーションでコントラクトによる小さな設計を試してみたかったので、次のような構文を使用したいと考えていました。

単体テスト フレームワークからこのような静的メソッドを取得できることはわかっていますが、このようなものが既に言語に組み込まれているのか、それとも何らかのフレームワークがすでに存在しているのかを知りたかったのです。車輪を再発明したくないだけで、独自のアサート関数を作成できます。

nullをチェックする必要がない場合のガイドラインは何ですか？

私が最近取り組んできた継承されたコードの多くは、nullチェックと悪意を持っています。些細な関数のnullチェック、null以外の戻り値を示すAPI呼び出しのnullチェックなど。場合によっては、nullチェックは妥当ですが、多くの場合、nullは妥当な期待ではありません。

「他のコードを信頼できない」から「常に防御的にプログラムする」、「言語がnull以外の値を保証するまで、常にチェックする」など、さまざまな議論を聞いています。私は確かにこれらの原則の多くにある程度同意しますが、過度のnullチェックは、通常これらの原則に違反する他の問題を引き起こすことがわかりました。粘り強いヌルチェックは本当に価値がありますか？

頻繁に、過剰なnullチェックを含むコードは、実際には高品質ではなく、低品質であることがわかりました。コードの多くはnullチェックに重点を置いているため、開発者は読みやすさ、正確さ、例外処理などの他の重要な品質を見失っています。特に、多くのコードがstd :: bad_alloc例外を無視しているのがわかりますが、。に対してnullチェックを実行しますnew。

C ++では、nullポインターを逆参照するという予測できない動作のために、これをある程度理解しています。null逆参照は、Java、C＃、Pythonなどでより適切に処理されます。注意深いnullチェックの悪い例を見たことがありますか、それとも本当に何かありますか？

私は主にC++、Java、およびC＃に関心がありますが、この質問は言語に依存しないことを目的としています。

過剰に見えるヌルチェックの例には、次のものがあります。

この例では、C ++仕様では、失敗したnewが例外をスローすると述べているため、非標準のコンパイラを考慮しているようです。非準拠のコンパイラを明示的にサポートしていない限り、これは意味がありますか？これは、JavaやC＃（またはC ++ / CLR）のような管理された言語では意味がありますか？

もう1つの例は、内部コードで作業する場合です。特に、独自の開発手法を定義できる小さなチームの場合、これは不要のようです。一部のプロジェクトやレガシーコードでは、ドキュメントを信頼することは合理的ではないかもしれません...しかし、あなたやあなたのチームが管理する新しいコードの場合、これは本当に必要ですか？

表示して更新できる（または責任のある開発者に怒鳴ることができる）メソッドにコントラクトがある場合でも、nullをチェックする必要がありますか？

プライベート関数またはその他の内部関数を開発する場合、コントラクトがnull以外の値のみを要求する場合、nullを明示的に処理する必要が本当にありますか？なぜアサーションよりもヌルチェックの方が望ましいのでしょうか？

（明らかに、パブリックAPIでは、APIを誤って使用したことでユーザーに怒鳴るのは失礼だと考えられているため、ヌルチェックは不可欠です）

に比べ：

私はグループの開発プロセスの改善に取り組んでおり、テスト駆動開発による契約による設計をどのように実装するのが最善かを検討しています。2 つの手法には多くの重複があるようです。次の (関連する) 質問について誰かが洞察を持っているかどうか疑問に思っていました。

• コントラクトに基づいて単体テストを生成するために何らかのコード ジェネレーターを使用していない限り、TDD と DbC を使用するのは DRY の原則に反していませんか? そうしないと、2 つの場所 (テストとコントラクト自体) でコントラクトを維持する必要があります。
• TDD は DbC をどの程度冗長にしますか? テストを十分に書けば、それは契約書を書くことと同等ではないでしょうか? テストだけでなく、実行時にもコントラクトを強制した場合にのみ、追加のメリットが得られますか?
• DbCでTDDを使用するのではなく、TDDのみを使用する方がはるかに簡単/柔軟ですか?

これらの質問の主なポイントは、より一般的な質問です:既に適切に TDD を実行している場合、DbC も使用すると、オーバーヘッドに対して大きなメリットが得られるでしょうか?

質問は主に言語に依存しないと思いますが、いくつかの詳細：

• 私たちのチームは非常に小さく、プログラマーは 10 人未満です。
• 主にPerlを使用しています。

この質問を投稿してその質問を読んだ後、メソッドが null を返すことになっているかどうか、またはこれがエラー状態と見なされて例外をスローする必要があるかどうかを知ることが非常に重要であることに気付きました。'null'を返すか、例外をスローするかについても、適切な議論があります。

メソッドを作成していて、null を返すか、例外をスローするかは既にわかっています。私の決定を表現する、つまり契約を文書化する最善の方法は何ですか?

私が考えることができるいくつかの方法：

• 仕様/ドキュメントに書き留めてください（誰かがそれを読みますか？）
• メソッド名の一部にします（ここで提案したように）
• 例外をスローするすべてのメソッドが null を返すことはなく、スローを「しない」すべてのメソッドが null を返す可能性があると想定します。

私は主に Java について話していますが、他の言語にも当てはまるかもしれません: 例外がスローされるかどうかを表す正式な方法 (throwsキーワード) があるのに、null が返される可能性があるかどうかを表す正式な方法がないのはなぜですか?

なぜそのようなものがないのですか：

まとめと結論

契約を表現する方法はたくさんあります。

• IDE が (IntelliJ として) サポートしている場合は、 のような注釈を使用することをお勧めします。@NotNullこれは、プログラマーに表示され、コンパイル時の自動チェックに使用できるためです。これらのサポートを追加するEclipse 用のプラグインがありますが、私にはうまくいきませんでした。
• これらがオプションでない場合は、Option<T>またはNotNull<T>のようなカスタム タイプを使用して、明確さと少なくともランタイム チェックを追加します。
• いずれにせよ、JavaDoc でコントラクトを文書化することは決して悪いことではなく、時には役立つこともあります。
• メソッド名を使用して戻り値のnull可能性を文書化することは、私以外の誰も提案していません。非常に冗長で常に役立つとは限りませんが、それでも利点がある場合があると私は信じています。

コンパイラーがコンパイル時に dbc を強制できることを読みました.どのようにそれを行うのですか?