c# - 使い方 - unity ラムダ式




ラムダ式とプライベートメソッドの使用 (5)

スタックオーバーフローに関する質問には、次のようなコードが含まれています。

Action<Exception> logAndEat = ex => 
{  
    // Log Error and eat it
};

try
{
    // Call to a WebService
}
catch (SoapException ex)
{
    logAndEat(ex);
}
catch (HttpException ex)
{
    logAndEat(ex);
}
catch (WebException ex)
{
    logAndEat(ex);
}

私の質問は、(私の見解ではもっと簡単で明白な)プライベートメソッドとは対照的に、LogAndEatのラムダ式を以下のように使用することの利点は何ですか:

private void LogAndEat(Exception ex)
{
    // Log Error and eat it
}

編集:これまでの回答をありがとうが、ちょうど私の根本的な質問をもう少し明確に再:どのアプローチが良いですか、このインスタンスでお勧めですか? ラムダ式またはプライベートメソッド?


IMO私は私のクラスの周りに疑問に思っている別のプライベートメソッドでのみ使用される小さな小さなプライベート関数を好きではありません。私はそれらが醜いと思うので、そのサンプルでラムダを使用します

私は関数の代わりにラムダを使用するとパフォーマンスに影響が出るとは思わない


LogAndEatは、定義されている関数内のプライベートフィールドを参照できます。 そう:

private bool caughtException; 

Action<Exception> logAndEat = ex => 
    {  
        caughtException = true;
    };

try
{
    // Call to a WebService
}
catch (SoapException ex)
{
    logAndEat(ex);
}
catch (HttpException ex)
{
    logAndEat(ex);
}
catch (WebException ex)
{
    logAndEat(ex);
}

if (caughtException)
{
    Console.Writeline("Ma, I caught an exception!");
}

これは漠然とした例です(!)が、これはプライベートメソッドに一連のパラメータを渡すよりも、潜在的に非常に細かいことがあります。


この例のラムダ式は、宣言されたメソッドでしか実行できないコードであるという点で、Pascalのネストされた関数に少し似ていると考えることができます。

プライベートメソッドは同じクラスの任意のメソッドから呼び出すことができますが、このようなラムダは現在のメソッドに対してローカルなので、そのコンテキストでのみ明示的に使用されます。

これは、私が考えることができる唯一の利点です。期待される使用法に関して明白です。


ラムダ式( 元の答えと同じように)を使用する方が良いか、「適切な」方法を使用するかを理解するには、一般的なエラー処理コードの再利用可能性に基づいて判断する必要があります。

  • 一般的なエラー処理コードがアプリケーション間で異なるクラスの他の関数によって完全に再利用可能な場合は、おそらくコード構成をより分かりやすくするために、別のクラスにある内部関数またはパブリック関数である必要があります。

  • 共通のエラー処理コードが同じクラスの他の関数だけによって再利用可能である場合、それはおそらく同じクラスのプライベート関数であるべきです。

  • 一般的なエラー処理コードが他の関数によって再利用可能でなく、この特定の関数によってのみ使用されるべきである場合は、2つの選択肢があります。 最初に、デリゲートを使用して関数の境界内にカプセル化し、関数が実装の詳細を漏らさないようにします。 2つ目は、同じクラスのプライベート関数を、それが意図している関数によってのみ呼び出されるべきであるというコメントと共に使用することです。

3番目のケースでは、同じ目標を達成するための完全な正当な方法であるため、明確な「最良の方法」はありません。 私の傾向は、共通コードが小さい場合や、変数をキャプチャするような代理人の動作が必要な場合に代理人を使用することです。

今、質問に戻って、なぜ私はデリゲートを使ってコードを書いたのですか? 私はエラー処理コードが再利用可能かどうかについての情報は持っていなかったので、そうではないと仮定し、デリゲートを使用することに決めました。人々がこれを簡単に見つけることができれば、 (あなたが持っているように)メソッドを使用していますが、私が「適切な」関数を使用している場合、人々は代理人が代案になることを認識しないかもしれません。


皆さん、ありがとうございました。投票した偉大な回答をお寄せいただきましたが、賛否両論を1つの答えに取り入れるように要約したと思いました。

プライベートメソッドの代わりにラムダ式(LE)を使用する利点:

  • LEは宣言されているメソッドにスコープが設定されているため、そのメソッドでのみ使用されている場合は、ラムダ式でその意図が明示されます(LEにデリゲートを渡すことは可能ですが、メソッドでLEを宣言する意図は、LEがそのメソッドにスコープされていることです)。 つまり、期待される使用法の観点から明白です。
  • ラムダ式はクロージャのように振舞い、宣言されたメソッドにスコープされた変数にアクセスすることができます。これは、プライベートメソッドに多くのパラメータを渡すよりも簡単です。
  • LEによって捕捉された変数は、さもなければプライベートメソッドへのパラメータとなり、カリングの形式を可能にするためにこれを利用することができます。

プライベートメソッドの代わりにラムダ式を使うことの短所:

  • LEは、それらが含まれているメソッドにスコープされた変数にアクセスできるため、デバッグ中に呼び出しメソッド内のコードを変更することはできません。

メンテナンス性の主観的な問題もあり、LEはほとんどの開発者によって私的な方法としてよく理解されておらず、したがって保守性はやや劣ると主張することができます。 LEはクラス全体に見えるプライベートメソッドとは対照的に呼び出されるメソッドにカプセル化されているため、LEはメンテナンス性を向上させると主張することもできます。





lambda