メソッドは、彼らが呼ぶメソッドと同じ前提条件を持つべきですか?
-
11-10-2019 - |
質問
私は最近、コードの小さな変更が複数のクラスにわたって前提条件の変更をもたらしたいくつかのシナリオを持っていました、そして、私は契約による設計がそのように想定されるかどうか疑問に思っていました。
public Goal getNextGoal() {
return goalStack.pop();
}
もしも goalStack.pop()
スタックが空ではないという前提条件があります。 getNextGoal()
明示的に同じ前提条件を持つ必要がありますか?前提条件を継承すると物事が脆くなるように思われ、キューや他の構造に変更すると、前提条件が変更されます。 getNextGoal()
, 、それは発信者であり、発信者の発信者です。しかし、前提条件を継承しないと契約が隠され、発信者が発信者の発信者を隠すことは、前提条件について知らないようです。
そのため、すべての発信者がコードのコードの前提条件と事後条件を知って継承する脆弱なコード、または発信者がより深い前提条件と事後条件が何であるかを知らない神秘的なコード?
解決
それはあなたの呼び出し方法が正確に何をするかによって異なります。 前提条件の重要なことは、発信者が前提条件を満たす責任があることです.
したがって、getNextgoalメソッドの発信者が空でないスタックを提供する責任がある場合は、実際にgetNextgoalメソッドの前提条件を設定する必要があります。前提条件の明確さは、コード契約の大きな利点の1つであるため、発信者が前提条件を満たす必要があるすべての場所にそれらを置くことをお勧めします。
しかし、あなたのコードが脆いように見える場合、 それはあなたがいくつかのコードをリファクタリングする必要があるという兆候かもしれません.
前提条件を継承すると物事が脆くなり、キューまたは他の構造に変更すると、前提条件が変更されます。
キューを発信者に公開し、後で(あなたが言ったように別の構造に)変更すると、発信者も変更する必要があります。これは通常、脆性コードの兆候です。
あなたが露出する場合 特定のキューの実装の代わりにインターフェイス, 、前提条件もインターフェイスを使用する可能性があり、実装が変更されるたびに前提条件を変更する必要はありません。したがって、脆いコードが少なくなります。
他のヒント
例外は1つの解決策ですが、おそらくあなたの状況では実行可能ではありません。
目標がない場合に何が起こるかを文書化することは正常です。
各言語がその特定の言語に対してわずかに自然な方法を持っている可能性があるため、JavaまたはC ++を使用しているのか、何か他のものを使用しているのかはわかりません。