ベストプラクティス-関数呼び出しの周りをラップするvs関数内でガードする場合は早期終了を追加する

これは非常にユースケース固有のものになる可能性があることは知っていますが、私はあまりにも頻繁にこれに疑問を感じています。一般的に推奨される構文はありますか？

私は関数の中で最善の方法を尋ねているのではなく、早く終了するか、関数を呼び出さないかを尋ねています。

関数呼び出しの周りをラップする

if (shouldThisRun) {
  runFunction();
}

持っている場合（ガード）機能で

runFunction() {
  if (!shouldThisRun) return;
}

後者のオプションは、この関数が複数回呼び出された場合にコードの重複を減らす可能性があることは明らかですが、関数の単一の責任性を失う可能性があるため、ここに追加すると間違っていると感じる場合があります。

例はこちら

何かのステータスを更新するupdateStatus（）関数がある場合。ステータスが変更された場合にのみステータスを更新します。ステータスが変更される可能性があるコード内の場所を知っています。

私だけかどうかはわかりませんが、この関数をできるだけ純粋にしたいので、この内部関数をチェックするのは少し汚れています。これを呼び出すと、ステータスが更新されることが期待されます。しかし、変更を加えていない可能性があることがわかっているいくつかの場所で、呼び出しをチェックでラップする方がよいかどうかはわかりません。

関数呼び出しの周りにifをラップする：
これは、関数を呼び出すかどうかを決定することであり、プログラムの意思決定プロセスの一部です。

関数内のガード句（早期復帰）：
これは、無効なパラメーターで呼び出されないようにするためです。

この方法で使用されるガード句は、関数を「純粋」に維持します（ユーザーの用語）。これは、誤った入力データによって関数が中断しないようにするためにのみ存在します。

関数を呼び出すかどうかについてのロジックは、たとえそれが単にであっても、抽象化のより高いレベルにあります。関数自体の外に存在する必要があります。DocBrownが言うように、コードを簡略化するために、このチェックを実行する中間関数を持つことができます。

これは良い質問であり、抽象化のレベルの認識につながる一連の質問に含まれます。各関数は、抽象化の一つのレベルで動作し、プログラムロジックと機能における機能ロジックの両方を持つことはあなたに間違って感じている必要があります-彼らはので、これはある抽象化のさまざまなレベルで。関数自体は下位レベルです。

これらを分離しておくことで、コードの書き込み、読み取り、保守がより簡単になります。

あなたは両方を持つことができます-パラメータをチェックしない関数と、このようにチェックする別の関数です（おそらく、呼び出しが行われたかどうかについての情報を返すでしょう）：

bool tryRunFunction(...)
{
    bool shouldThisRun = /* some logic using data not available inside "runFunction"*/;
    if (shouldThisRun)
        runFunction();
    return shouldThisRun;
}

そうすれば、再利用可能tryRunFunctionを提供することでロジックの重複を回避し、内部でチェックを行わない元の（多分純粋な）関数を保持できます。

場合によってtryRunFunctionは、統合されたチェックのような関数を排他的に必要とするため、チェックをに統合できることに注意してくださいrunFunction。または、プログラム内の任意の場所でチェックを再利用する必要はありません。その場合は、チェックを呼び出し側の関数に残しておくことができます。

ただし、関数に適切な名前を付けることにより、呼び出し側に何が起きるかを透過的にするようにしてください。したがって、呼び出し側は、自分でチェックを行う必要がある場合、または呼び出された関数がすでにチェックを行う場合、実装を推測したり調べたりする必要はありません。try多くの場合、のような単純なプレフィックスで十分です。

実行するかどうかを誰が決めるかについては、答えはGRASPから、誰が知っている「情報専門家」であるかです。

決定したら、わかりやすくするために関数の名前を変更することを検討してください。

このような何か、関数が決定した場合：

 ensureUpdated()
 updateIfDirty()

または、発信者が決定することになっている場合：

 writeStatus()

@Baldrickkの答えを詳しく説明します。

あなたの質問に対する一般的な答えはありません。呼び出される関数の意味（契約）と条件の性質によって異なります。

それでは、例の呼び出しのコンテキストでそれを説明しましょうupdateStatus()。ステータスに影響を与える何かが発生したため、契約はおそらく一部のステータスを更新することです。そのメソッドへの呼び出しは、実際のステータス変更がなくても許可され、実際に変更がある場合に必要になると思います。

したがって、呼び出し元のサイトはupdateStatus()、（ドメイン期間内で）関連する変更が何もないことを知っている場合、呼び出しをスキップできます。これは、呼び出しが適切なif構成で囲まれるべき状況です。

updateStatus()関数内では、この関数が（ドメインホライズン内のデータから）何もすることがないことを検出し、それが早期に戻る必要がある状況がある場合があります。

したがって、質問は次のとおりです。

• 外部から見ると、関数のコントラクトを考慮して、関数を呼び出すことが許可/要求されるのはいつですか？
• 関数内で、実際の作業なしで早期に戻ることができる状況はありますか？
• 関数を呼び出すかどうか、早期に戻るかどうかの条件は、関数の内部ドメインまたは外部に属していますか？

updateStatus()関数を使用すると、両方が表示され、何も変更されていないことがわかっているサイトを呼び出し、呼び出しをスキップし、実装が「何も変更されていない」状況を早期にチェックします。内外。

多くの良い説明があります。しかし、私は変わった見方をしたいのですが、次のように使用するとします。

if (shouldThisRun) {
   runFunction();
}

runFunction() {
   if (!shouldThisRun) return;
}

そして、あなたはrunFunctionこのようなメソッドで別の関数を呼び出す必要があります：

runFunction() {
   if (!shouldThisRun) return;
   someOtherfunction();
}

あなたは何をしますか？すべての検証を上から下にコピーしますか？

someOtherfunction() {
   if (!shouldThisRun) return;
}

私はそうは思いません。したがって、私は通常同じアプローチを行いますpublic：入力を検証し、メソッドの条件をチェックします。 パブリックメソッドは独自の検証を行い、呼び出し元が行う場合でも必要な条件をチェックする必要があります。ただし、プライベートメソッドは独自のビジネスを実行するだけです。他の一部の関数はrunFunction、検証や条件の確認を行わずに呼び出す場合があります。

public someFunction() {
   if (shouldThisRun) {
      runFunction();
   }
}

private runFunction() {
 // do your business.
}