例外は有効な事後条件ですか？</em>は、すべての有効な入力され</p> <pre><code>public interface AISPI { public Path getPath(Entity entity, Entity target, World world) throws NoPathException; } </code></pre> <p>確か<em>そのエンティティ</em>、<em>ターゲット</em>、および<em>世界：

Question

は、次のインタフェースを考えてみましょう。しかし、パスを見つけるために使用されたアルゴリズム（この場合はAstarです）は、パスを見つけることができません。 ターゲットの位置はコンクリートの壁で囲まれています。

は、事後条件がエンティティにターゲット（目標に開始）または（パスが見つからなかったことを考えると）NoPathExceptionからパスのいずれかであることの状態には有効ですか？
- は、開始から終了までの有効なパスが必要であるという前提条件がありますか？

これは宿題ではありませんが、私たちの学期プロジェクトレポートを改善するための質問です。私はどのフレームワークについても学ぶつもりはないが、これは純粋に契約による設計に関する標準と手続きの問題である。この問題の説明をありがとう。

Answer 1

用語の定義によって異なります。事後条件。一般に、の前提条件は、ルーチン入力時の入力状態と入力値の関係であり、事後条件はルーチン終了時の入力状態と入力値と出力状態と出力値の関係です。

ルーチンは通常または例外的に終了することができるため、正常終了のための事後条件と異常終了のための事後条件を定義することができます。明らかに両方とも入力値、入力状態および出力状態を含む。主な違いは出力値です。最初のケースでは、これはルーチンシグネチャで指定された値で、2番目の場合は言語に依存します。あなたの例では、NoPathExceptionかもしれませんが、メモリ割り当てエラー、スタックオーバーフロー、または署名に指定されていないその他の例外やシグナルがある場合はどうなりますか？確かに、例外を伴わない有効な結果が常に存在することを保証する前提条件を持つことが可能であるように見えるかもしれません。しかし、これは当てはまりません。同時実行性などがあります。また、前提条件が計算するにはコストがかかりすぎる場合は、同じ作業を2回行うことはうれしくありません。クライアント側では、コールが適用可能であることを確認し、サプライヤ側で結果を得るために本質的に同じ計算を行うこと。

Design by Contract哲学は、クライアントがルーチンを呼び出した後に安全に頼ることができるものです。例外的事例に戻ると、実用的な観点からは、プログラムが実行を続けることができるように、事後条件を十分に強力にすることが理にかなっていますが、署名に指定されていないか、実際には可能ですが、許可されています。

言語が実際にすべての例外的なケースを保証するものでなければ、最も重要な部分は、関連するオブジェクトを使用不可能にしてはならない出力状態です。そして、これは、明示的または暗黙的な事後条件またはクラス不変式として表現することができる。

getPathの具体例では、経路が存在しない、すなわち起こりうる状況が予想される状況が予想される。いくつかのガイドラインでは、正常終了を示すために通常の値を使用することを推奨しています。ここで値はnullとなります。nullを使用すると、結果がヌルネスであるかどうかがチェックされていない場合はNullPointerExceptionなど、呼び出し元側で他の問題が発生する可能性がありますが、そのような例外がないことを保証する言語では（例：Eiffel）経路がないことを示す好ましい方法です（その場合、戻りタイプはdetachable PATHになります）。