4

私の問題 (下記) のクリーンなデザインを考え出すことに行き詰まっています。私はパブ/サブまたはオブザーバーのパターンを考えましたが、正しく考えていない限り、私の問題はこれらのアプローチの反対のようです。メディエーターのパターンは機能するかもしれませんが、何らかの理由でまだ適切ではないようです。したがって、ここでどのような設計が必要かについての助けがあれば、私に知らせてください:)

私の問題は、複数のソースからのイベントを処理できるハンドラーが必要なことです。複数の場所からイベントを管理できるホットキー マネージャーが必要です。すなわち。キーが押された場合、何らかのアクションが発生するはずです。または、マイク (別のソース) でボタンが押された場合、アクションが発生するはずです。

私の現在のアイデアは、マネージャーをシングルトンとして実装し (これは大ファンではありません...)、クラスをマネージャーに登録することです。クラスは、(登録時に) マネージャーがアタッチする特定のイベントを保証するインターフェイスを実装する必要があります。クラスがこのイベントを発生させる必要があるため、これは好きではありません。これは、契約自体によって保証されているものではありません

4

1 に答える 1

3

あなたの現在のアイデアはうまく聞こえますが、次の調整を行います。

  • マネージャーがシングルトンである必要はありません。

  • イベント ソースは、ホットキー マネージャーに自分自身を登録する必要はありません。他のクラス (ビルダー) がイベント ソースをマネージャーに登録する役割を果たします。これにより、マネージャーのソースから依存関係が削除されます。

例えば

public class HotKeyManager
{
    public void RegisterKeySource(IKeySource source)
    {
        source.OnKeyPress += this.KeyPressHandler;
    }

    public void KeyPressHandler(object sender, KeyPressEventArgs args)
    {
        // ...
    }

    // ...
}

public interface IKeySource
{
    event EventHandler<KeyPressEventArgs> OnKeyPress;

    // ...
}

他のいくつかのクラスがソース登録を処理します。

var hotKeyManager = new HotKeyManager();

var keySource = new MyKeySource(); // Implements IKeySource

hotKeyManager.RegisterKeySource(keySource);
于 2012-12-23T05:23:34.257 に答える