データを独立スレッドにリアルタイムで収集するAPIを作成したとします。データアクセスはスレッドセーフで、インターフェイス経由で行われます。例えば。 getData()はブロックされず、最新の情報を提供します。このAPIは、多くのアプリケーションで使用されています。いくつかのGUI駆動、他のコンソールプログラム。Java：自分のAPIでイベント通知のオプションは何ですか？
アプリケーションにデータ更新があったことを通知するには、どのようなオプションが必要ですか？私たちは間違いなくAPIがアプリケーションに依存しないようにするため、fireTableDataChanged()またはそのようなAPIのものは望ましくありません。 （GUIアプリケーションでは、APIが私たちに通知した後、またはAPIを見てからfireTableDataChanged()などと呼ぶでしょう）
ありがとう！
1つのオプションは、独自のイベントプロデューサクラスを作成することです。
IEventListenerはオブザーバによって実装されます。それはイベントを受け取るためのメソッドを持っています。
IEventProducerは、EventProducerを介して観測可能で実装されています。リスナーの追加と削除のためのメソッドがあります。
EventProducerはスレッドセーフです。リスナーのCopyOnWriteArrayListにイベントを送信するメソッドがあります。リスナーによってスローされた例外をキャッチしてログに記録します。また、リスナーを追加および削除するためのメソッドも用意されています。
次に、観察可能なクラスは、内部のEventProducerを介してIEventProducerを実装できます。
同じクラスの2つのリスナータイプをサポートしようとすると、erasureを使用するには、異なるリスナーに対して別々に追加/削除リスナーメソッドの名前を付ける必要があります。
ObservableとObserverをご覧ください。私はそれらを個人的に使用していないし、APIを見て、私がそれを気にすることを完全には確信していない。基本的に、観測可能なデータオブジェクトは、Observableクラスから拡張する必要があります。データに関心のあるクラスは、Observerインターフェイスを実装し、データオブジェクトに登録する必要があります。このAPIは1.0以降存在しており、汎用ではありません。しかし、これは私が知っているJavaライブラリの唯一のObserver/Observableパターンです。
基本的に2つのオプションがあります。
1）APIにポーリングして、新しいデータがあるかどうかを確認します。
2）新しいデータがあるときに通知するAPIを取得します。
通知するAPIをObserverパターンで取得することができます。 ObservableとObserverを使用する必要はありません。独自のインターフェイスを作成できます。基本的には次のように動作します。
（1）と（2）の間の決定に問題がありますか？ （2）は（1）よりずっと複雑です。したがって、私は 'getData（）'をブロックするか、またはAPIをポーリングして、そこから取り除くことができると考えています。 – Pete
+1 - 恐ろしいほど、私は「自分で実装する」といいます。オブザーバーを定期的に追加したり削除したりする場合は、java.awt.AWTEventMulticasterで使用されるスレッドセーフイベントマルチキャストロジックの後でEventProducerをモデリングして最適化することができます。 –
<の解析を修正するように編集されました。 @ティム、私はそのような共通のパターンのために "あなた自身の実装"がひどいと思うことに同意します。標準がない場合、1つの社内実装は、多くの異なるクラスごとの実装よりも優れています（いくつかの不幸な経験から）。私は、リスナーの追加/削除が最適化される必要がある状況に遭遇したことはありません。 AWTEventMulticasterは、Java並行処理パッケージおよびCopyOnWriteArrayListenerの日付を事前に設定しています。これにより、シンプルで読みやすいスレッドセーフな実装が可能になります。 –
あなたの答えに感謝します。あなたが概説したものを実装するのか、それとも 'getData（）'をブロックするようにAPIをポーリングするのかをどうやって決めますか？問題は何ですか？ – Pete