空のイベントハンドラを常に追加しても問題ありませんか？

Question

可能性の重複：

public event Action handler; … // some method: if(handler != null) handler(); 

が空を割り当てる任意の欠点がある：（C＃で）イベントハンドラを使用する場合
Is there a downside to adding an anonymous empty delegate on event declaration?

次のパターンは、非常に一般的ですこのイベントにデリゲートしますか？これにより、イベントが発生したどこの場所でもif !=nullの状態が保存されます。もちろん、これは、イベントが常に適切な代理人に割り当てられることを保証できない場合にのみ適用されます。

public event Action handler; 
… 
// in constructor: 
handler +=()=>{}; 
… 
// some method: 
handler(); 

確かに、そこにわずかなパフォーマンスヒットだが、それは、コードがはるかにきれいになります。そのような場合のベストプラクティスは何ですか？技術的に不利な点はありますか？

Answer 1

コンストラクタに空のデリゲートを追加する代わりに、ハンドラがヌルであるかどうかを最初に確認してから呼び出す関数でハンドラをラップすることができます。これの欠点は、多くのイベントがある場合、各イベントをラップする多くの機能があることです。

private void HandlerWrapper() 
{ 
    Action localHandler = handler; 
    if (localHandler != null) handler(); 
} 

Answer 2

興味深い考えでは、私はこれをやったことは考えていません。私のカスタムイベントのやり方は、イベントのパラメータを取るOnCustomEventNameを作成し、nullをチェックするだけです。私はどこからトリガされるイベントをしたいコードのOnCustomEventNameを呼び出します。 イベントを発生させるたびに、パフォーマンスのヒットを回避し、操作コードを2行よりもきれいに保ちます。

これは、技術的な欠点についての質問には答えていませんが、イベントを発生させるときのベストプラクティスについては、より多くのことが言われています。

スレッドセーフ "オン"機能のサンプルコードです。

private void OnCustomEventName() 
{ 
    DelegateName localhandler = CustomEventName; 
    if (localhandler != null) 
     localhandler(); 
} 

Answer 3

これを行うには大きな欠点はありませんでしたが、一般的にはnullをチェックするのが好ましいです。私が考えることができない唯一の問題は、デバッグ時にコード内の厄介なステップにつながる可能性があるということです（つまり、イベントに入るたびに空のデリゲートをステップオーバーする必要があります。 ）。

私は、パフォーマンスは問題ではないと考えています。アプリケーションのパフォーマンスがイベントを呼び出すことによって大幅に悪化した場合、イベントはおそらく最初にそこにあったはずです。