web-dev-qa-db-ja.com

自分自身を育てるイベント-それは複雑すぎますか？

少し問題があります。私は、ユーザーがリソースを要求し、リソースがロードされたときに呼び出される（および/またはロードが完了するのを待つ）コールバックを設定できる、リソースのロードおよびキャッシュシステムを作成しています。これにより、次のようなコードが生成されます。

var waitobj=Loader.RequestObject("foo");
waitobj.LoadFinished+=delegate{ Bar(); };

ただし、リソースはキャッシュされるため、RequestObjectの呼び出しは実際には同期的に完了する可能性があります。これは、コールバックが設定されている場合、リクエストはすでに終了しており、コールバックが呼び出されることはないことを意味します。私は巧妙なトリックを考えました：イベント加算器自体でリクエストの状態をチェックしましょう！

public event LoadFinishedHandler LoadFinished {
    add {
        if(Finished)
            value();
        else
            m_LoadFinished+=value;
    }
}

これは何があってもコールバック関数を呼び出します。しかし、私の同僚は、このメソッドは複雑すぎて、誰もこのコードを維持できないと言いました。私はとにかくこのトリックが好きです、しかし私は明らかに偏見があります。

あなたはどう思いますか、このトリックはそれ自体の利益のためにあまりにも巧妙ですか？

c#maintainability
2
Nevermind

あなたの同僚がどこから来ているのかわかります。それは危険なアプローチのようです。

この状況のほとんどの人は次のようなことをします：

Loader.BeginRequestObject("foo", Bar);

次に、BeginRequestObjectはスレッドを開始して、RequestObjectで実行していることをすべて実行し、すぐに戻ります。スレッドが完了すると、Bar（）が呼び出されます。

これは、このような状況のイベントモデルよりもはるかに堅固です。イベントモデルは、プロセス中にイベントがいつ発生するかを知りたいと考えているリスナー（スレッドが始まる前にフックできる）が多数いるオブジェクトがある場合に、より便利です。

2
pdr

古い格言があります：

「デバッグは、そもそもコードを書くよりも2倍難しいです。したがって、コードをできるだけ巧妙に書くと、定義上、デバッグするほど賢くなりません。」 -ブライアン・カーニハン

それがコードにとって何を意味するのかを調べてください。 ;）

1
JUST MY correct OPINION