3

UDP メッセージを受信して​​解析するシステム用の API を構築しています。次に、これらの変更について開発者に通知する必要があります。

現在、2 つの実装を考えていますが、どちらが優れているか、他のオプションがあるかどうかはわかりません。

ソリューション A ArrayBlockingQueue

アイドリング時はほとんど電力を消費しないようです。API 側では、静的配列を作成し、新しい変更について通知したいときにメッセージを追加するだけです。したがって、開発者側では、それをスレッドに入れて、新しいメッセージをリッスンすることができます。ユーザーはメッセージを取得し、そのタイプとプロパティなどを確認します。

ソリューション B コールバック

このソリューションは、より美しく、より整理されたものになると思います。考えられるすべての通知タイプを持つインターフェイスを作成するだけで、開発者はこのインターフェイスを実装できます。API側では、APIが複数の同じタイプのリスナーに通知できるように、同じリスナーのハッシュマップを持っています。

他にアイデアや提案はありますか？

4

2 に答える 2

4

イベントベースのシステムでは、非同期ソリューションが強く推奨されます。お気づきのように、各イベントレシーバーごとにスレッドが必要なブロッキングソリューションよりも軽量です。したがって、ソリューション B が優先されます。

ただし、注意すべきことの 1 つは、スレッド化の問題です。コールバックは独自のスレッドで呼び出すことになるため、コールバックの実装者はそれに対処する準備をしておく必要があります。コールバック コードは、特定のスレッドで実行されると想定してはなりません。毎回異なるスレッドで実行することもできます。

于 2013-05-20T13:17:12.740 に答える
2

オブザーバーパターンは、特に同じサブジェクトに対して複数のリスナーを持つことができる場合に役立ちます。

リスナーのハッシュマップを定義する代わりに、リスナーの CopyOnWriteArrayList を使用できます。このアプローチでは、新しいリスナーを追加しても、リスナーの繰り返しに干渉しません。

考えられるすべての通知タイプを受け入れるインターフェースを定義する代わりに、考えられるすべての通知タイプのルート クラスまたはインターフェースを受け入れる単一のメソッドを使用してインターフェースを定義することもできます。たとえば、このインターフェイスは、パラメーター化された型 EVENT をサブクラス化する任意のイベント オブジェクトを受け取ることができます。

public interface IObserver<EVENT> {
    public void receive( @NonNull EVENT event );
}
于 2013-05-20T13:18:41.273 に答える