6

重複の可能性:
イベント宣言に匿名の空のデリゲートを追加することの欠点はありますか?

次のパターンは、(C# で) イベント ハンドラーを使用する場合に非常に一般的です。

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

このイベントに空のデリゲートを割り当てることの欠点はありますか? if !=nullこれにより、イベントが発生するすべての場所で条件が保存されます。もちろん、これは、イベントに常に適切なデリゲートが割り当てられていることを保証できない場合にのみ適用されます。

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

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

4

3 に答える 3

1

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

private void HandlerWrapper()
{
    Action localHandler = handler;
    if (localHandler != null) handler();
}
于 2012-05-24T11:44:03.927 に答える
1

面白いアイデア、私はそれをやろうと思ったことはありません。カスタム イベントを行う方法は、イベントのパラメーターを取得する OnCustomEventName を作成し、そこで null をチェックするだけです。イベントをトリガーしたい場所ならどこでも、コードから OnCustomEventName を呼び出します。イベントを発生させるたびにチェックする場合、パフォーマンスの低下を回避し、操作コードを 2 行よりもクリーンに保ちます。

そうは言っても、これは技術的な欠点に関する質問への回答ではなく、イベントを発生させる際のベスト プラクティスです。

スレッドセーフな「オン」関数のコード例。

private void OnCustomEventName()
{
    DelegateName localhandler = CustomEventName;
    if (localhandler != null)
        localhandler();
}
于 2012-05-24T11:44:15.220 に答える
0

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

パフォーマンスは問題ではないと思います。イベントを呼び出すことによってアプリケーションのパフォーマンスが大幅に低下した場合、そもそもイベントが発生していないはずです。

于 2012-05-24T11:50:33.510 に答える