メソッドが不正な入力を返すことができないことがわかっている場合でも、メソッド呼び出しの戻り値を検証する必要がありますか？

呼び出しているメソッドがそのような期待を満たしているとわかっていても、メソッドが呼び出した期待値を満たしていることを検証することで、メソッド呼び出しの戻り値に対して防御する必要があるかどうか疑問に思っています。

与えられた

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

私はすべき

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

または

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

概念レベルでこれを求めています。私が呼び出しているメソッドの内部動作を知っている場合。私が書いたのか、調べたからです。そして、それが返す可能性のある値の論理は私の前提条件を満たします。検証をスキップするのが「より良い」または「より適切な」のか、それとも常に合格する必要がある場合でも、現在実装しているメソッドを続行する前に間違った値から防御する必要がありますか？

すべての答えからの私の結論（気軽にあなた自身のものに来てください）：

• このメソッドは過去に誤動作することが示されています
• メソッドは信頼できないソースからのものです
• このメソッドは他の場所から使用され、事後条件を明示的に述べていません

• このメソッドはあなたのメソッドに近いものです（詳細は選択した回答をご覧ください）
• メソッドは、適切なドキュメント、タイプセーフティ、単体テスト、事後条件チェックなどの契約を明示的に定義します
• パフォーマンスが重要です（この場合、デバッグモードのアサートはハイブリッドアプローチとして機能します）

これは、getUserとmyMethodがどの程度変化する可能性があるか、さらに重要なことには、それらが互いに独立して変化する可能性の程度に依存します。

あなたは何とかgetUserメソッドは、これまでに、これまで将来変更しないことを確かに知っている場合は、[はい、それはそれは、検証の時間を無駄にしている限りとして、それを検証し、時間の無駄だi直後に3の値を持っているi = 3;の文。現実には、あなたはそれを知りません。ただし、知っていることがいくつかあります。

• これらの2つの機能は「一緒に」動作しますか？言い換えれば、彼らは彼らを維持している同じ人を持っていますか、彼らは同じファイルの一部ですか？したがって、彼らは自分自身で互いに「同期」したままになる可能性がありますか？この場合、2つの関数が変更されるか、異なる数の関数にリファクタリングされるたびに変更（および潜在的にバグ）しなければならないコードを単に意味するため、検証チェックを追加するのはおそらくやり過ぎです。

• getUser関数は、特定のコントラクトで文書化されたAPIの一部であり、myMethodは別のコードベースのAPIのクライアントにすぎませんか？その場合、そのドキュメントを読んで、戻り値を検証する（または入力パラメーターを事前検証する）必要があるかどうか、または盲目的にハッピーパスをたどることが本当に安全かどうかを確認できます。ドキュメントでこれが明確になっていない場合は、メンテナーに修正を依頼してください。

• 最後に、この特定の関数が過去に突然かつ予期せずに動作を変更した場合、コードを壊すような方法で、あなたはそれについて偏執する権利があります。バグは集中する傾向があります。

両方の機能の元の作成者であっても、上記のすべてが適用されることに注意してください。これらの2つの関数が残りの人生で「一緒に生きる」ことが期待されているのか、それとも別々のモジュールにゆっくりと移行するのか、または古いバグで自分の足を撃ったのかはわかりませんgetUserのバージョン。しかし、あなたはおそらくかなりまともな推測をすることができます。

Ixrecの答えは良いですが、検討する価値があると思うので、別のアプローチを取ります。この議論の目的のために、私はアサーションについて話しますPreconditions.checkNotNull()。それはあなたが伝統的に知られている名前だからです。

私が提案したいことは、プログラマーはしばしば、何かが特定の方法で動作することを確信している程度を過大評価し、そのように動作しないことの結果を過小評価するということです。また、プログラマはドキュメントとしてのアサーションの力に気付かないことがよくあります。その後、私の経験では、プログラマは物事を必要以上に頻繁に主張しません。

私のモットーは次のとおりです。

あなたが常に自問すべき質問は、「これを主張すべきか？」ではありません。しかし、「断言するのを忘れたものはありますか？」

当然、何かが特定の方法で動作することを完全に確信している場合、実際にそのように動作したと断言することは控えます。何も信用できない場合、ソフトウェアを書くことは実際には不可能です。

ただし、このルールにも例外があります。不思議なことに、Ixrecの例を挙げると、確かに特定の範囲内にあるint i = 3;アサーションに従うことが完全に望ましいタイプの状況が存在しiます。これは、iさまざまなwhat-ifシナリオを試みている人によって変更される可能性がある状況でありi、続くコードは特定の範囲内の値を持つことに依存しており、次のコードをすぐに見てもすぐにはわかりません許容範囲は次のとおりです。だから、int i = 3; assert i >= 0 && i < 5;最初は無意味に思えるかもしれませんが、考えてみると、で遊ぶことができるということとi、滞在しなければならない範囲を教えてくれます。アサーションはドキュメントの最良のタイプです。なぜなら、machineによって強制されるため、完全な保証であり、コードと一緒にリファクタリングされるため、常に適切です。

あなたのgetUser(int id)例は、このassign-constant-and-assert-in-range例のそれほど遠くない概念的なものではありません。定義によれば、予期した動作とは異なる動作が発生した場合にバグが発生します。確かに、すべてをアサートすることはできないため、デバッグが行われる場合があります。しかし、エラーを迅速に発見すればするほど、コストが削減されることは、業界では十分に確立された事実です。あなたが尋ねるべき質問はgetUser()、nullを決して返さない（そしてnull名のユーザーを返さない）ことだけでなく、他のコードでどのような悪いことが起こるかを確認することです実際、ある日、予想外の何かを返します。そして、コードの残りの部分をすばやく調べて、何が期待されていたかを正確に知ることは、どれほど簡単なことでしょうgetUser()。

予期しない動作によりデータベースが破損する場合、それが起こらないことを101％確信している場合でも、アサートする必要があるかもしれません。nullユーザー名によって、さらに数千行下の奇妙で不可解な追跡不可能なエラーが発生し、数十億クロックサイクルが遅れる場合、できるだけ早く失敗するのが最善です。

ですから、Ixrecの答えに異論はありませんが、アサーションに費用がかからないという事実を真剣に検討することをお勧めします。

明確ないいえ。

呼び出し元は、呼び出している関数がそのコントラクトを尊重しているかどうかをチェックしてはなりません。その理由は単純です。呼び出し元が非常に多くなる可能性があり、他の関数の結果をチェックするためのロジックを複製することは、すべての呼び出し元の概念的な観点から非現実的であり、間違いですら間違いです。

チェックを行う場合、各関数は独自の事後条件をチェックする必要があります。事後条件により、機能を正しく実装したこと、およびユーザーが機能の契約に依存できることを確信できます。

特定の関数がnullを返すことを意図していない場合、これを文書化し、その関数のコントラクトの一部にする必要があります。これがこれらの契約のポイントです。ユーザーが自分の関数を記述する際にハードルが少なくなるように、信頼できる不変条件をユーザーに提供します。

nullがgetUserメソッドの有効な戻り値である場合、コードは例外ではなくIfでそれを処理する必要があります-これは例外的なケースではありません。

nullがgetUserメソッドの有効な戻り値でない場合、getUserにバグがあります-getUserメソッドは例外をスローするか、修正する必要があります。

getUserメソッドが外部ライブラリの一部であるか、そうでなければ変更できず、nullリターンの場合に例外をスローする場合は、クラスとメソッドをラップしてチェックを実行し、例外をスローして、 getUserの呼び出しはコード内で一貫しています。

私はあなたの質問の前提がオフであると主張します：そもそもヌル参照を使用するのはなぜですか？

ヌルオブジェクトパターンは表していないオブジェクトを返す、あなたのユーザーのためではなく、戻り値はnull：基本的に何もしないリターン・オブジェクトへの道である「はユーザーを。」

このユーザーは非アクティブで、空の名前、および「ここには何もない」ことを示すその他の非ヌル値があります。主な利点は、オブジェクトを使用するだけで、チェック、ロギングなどを無効にするプログラムをポイ捨てする必要がないことです。

なぜアルゴリズムはヌル値を気にする必要があるのですか？手順は同じである必要があります。ゼロ、空の文字列などを返すnullオブジェクトを使用するのも同じくらい簡単ではるかに明確です。

nullのコードチェックの例を次に示します。

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

nullオブジェクトを使用したコードの例を次に示します。

return getUser().getName();

どちらが明確ですか？二つ目はそうだと思います。

質問にはjavaタグが付けられていますが、参照を使用する場合、C ++ではnullオブジェクトパターンが本当に役立つことに注意する価値があります。Java参照はC ++ポインターに似ており、nullを許可します。C ++参照は保持できませんnullptr。C ++のnull参照に類似したものが必要な場合、nullオブジェクトパターンがそれを達成する唯一の方法です。

一般に、それは主に次の3つの側面に依存すると言えます。

1. 堅牢性：呼び出しメソッドはnull値に対応できますか？null値が生じる可能性がある場合、RuntimeExceptionチェックをお勧めします-複雑性が低く、呼び出し/呼び出しメソッドが同じ作成者によって作成され、null予想されない場合（たとえば、両方privateが同じパッケージにある場合）。

2. コードの責任：開発者AがgetUser()メソッドに責任を負い、開発者Bがメソッドを（ライブラリの一部として）使用する場合、その値を検証することを強くお勧めします。開発者Bが潜在的なnull戻り値をもたらす変更について知らないかもしれないからです。

3. 複雑さ：プログラムまたは環境の全体的な複雑さが高いほど、戻り値を検証することをお勧めします。null呼び出し元のメソッドのコンテキストでは今日ではありえないと確信していてもgetUser()、別のユースケースのために変更する必要があるかもしれません。数か月または数年が過ぎ、数千行のコードが追加されると、これは非常にわなになります。

さらに、潜在的なnull戻り値をJavaDocコメントに文書化することをお勧めします。ほとんどのIDEでJavaDocの説明が強調表示されているため、これはを使用するすべてのユーザーに役立つ警告となりますgetUser()。

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

絶対にする必要はありません。

たとえば、戻り値がnullになることはないことが既にわかっている場合-なぜnullチェックを追加するのでしょうか？nullチェックを追加しても何も壊れませんが、冗長です。回避できる限り、冗長なロジックをコーディングしないことをお勧めします。