Javaのイベントリスナーとハンドラーの違いは何ですか？
Javaの一般的な用語では、イベントのリスナーとハンドラーがあります。
APIで利用可能なものであれば、知らないうちに使用します。
私の質問は、どのような場合にリスナーを使用し、どのような場合にイベントにハンドラーを使用するのかということです。
それらの違いは何ですか？特徴??
理由を探しましたが、Javaの適切な説明が見つかりませんでした。
リスナーとハンドラーの間に正式に定義された違いはありません。一部の人々は、おそらく互換性があると主張するでしょう。しかし、私にとっては、それらはわずかに異なる意味を持っています。
リスナーは、ソースからのイベントをサブスクライブするオブジェクトです。 Cf. observerパターン 。通常、イベントのタイプごとに多くのリスナーをサブスクライブさせることができ、それらはaddXyzListenerメソッドによってaddedされます。
例：Java API）の MouseListener .
ハンドラーは、特定のイベントの処理を担当するオブジェクトです。典型的なシナリオは、コンストラクターへの引数として特定のイベント/タスクのハンドラーを提供するか、setXyzHandlerメソッドを介してハンドラーをsetすることです。つまり、通常、イベントの種類ごとにoneハンドラーがあります。
例：Java API）の MemoryHandler .
最も基本的な違いは関連付けです
- リスナーはEvent Source（例：キーボード）に関連付けられています
- ハンドラーはEvent（例：keydown）に関連付けられています
一般的に、すべてのイベントを管理する中央のハンドラマネージャは1つだけですが、リスナの場合、リスンする各エンティティは、独自のリスナのコレクションを管理する必要があります。
これは私がそれを見る方法です：
A listener発生するイベントを監視します。たとえば、KeyListenerはKeyEventsを待ち、MessageListenerはキューにメッセージが到着するのを待ちます。
handlerは、イベントの処理を担当します。通常、リスナーとハンドラーは密接に関連しています。たとえば、KeyListenerはExitHandlerに「文字Qが押された」ことを伝え、ハンドラーはリソースのクリーンアップやアプリケーションの正常終了などのロジックを実行します。同様に、ButtonClickListenerは「Exitボタンがクリックされたこと」を同じExitHandlerに伝えます。そのため、この場合、2つの異なるイベント、2つの異なるリスナー、1つのハンドラーがあります。
リスナーは、イベントを記述するデータ値オブジェクトであるイベントをリッスンします。イベントが発生したとき、イベントの順序はしばしば重要です。キー「0」に続いて「1」を押すことは、「1」および「0」とは異なります。
ハンドラー。複雑なオブジェクトを処理します。新しいソケット接続。ハンドラーは、オブジェクトを任意の時間処理する場合があります。オブジェクトの作成と順序の時間はそれほど重要ではありません。 client0またはclient1からの接続は、任意の順序で発生する可能性があります。
具体的なリスナーもイベントハンドラーであるか、少なくともイベントハンドラーと見なすことができるメソッドを持っているため、違いは微妙だと思います。つまり、具体的なリスナーは、（event-sourceから）発生したばかりのイベントに関するすべての有用な情報を含むeventオブジェクトを（event-sourceから）受信した後、イベントに対する反応を処理または管理します。このリスナーは、イベントが発生したときにイベントソースオブジェクトによって順番に実行される少なくとも1つのメソッドを実装するように強制するxxxListenerインターフェースを実装する必要があるため、リスナー自体はハンドラー、より正確には、 Listenerオブジェクトによって実装されたListenerインターフェイスは、実際のイベントハンドラーと見なすことができます。したがって、イベントハンドラーは、イベントに反応して実行されるコードとしてのみ表示されます。これは、Observerデザインパターンなどのより抽象的な概念の要素であるListenerオブジェクトとは異なります。これは私の個人的な見解です。
私の考えでは、最も重要な違いは、イベントの種類ごとのハンドラーとは異なり、イベントのソースごとにリスナーを使用するという事実です。
リスナーは、イベントの発生時に通知されるオブジェクトであり、2つの主要な要件があります。1-特定のタイプのイベントに関する通知を受信するには、1つ以上のソースに登録されている必要があります2-受信および処理するメソッドを実装する必要がありますこれらの通知。ハンドラーはイベントの処理を担当します。
概念的には同じものです-UIイベントに応答して何らかのアクションを実行するオブジェクト。一般に、Swingでは、これらのオブジェクトは、ルックアンドフィールレベル（低レベルのウィジェットイベントを処理するため）では「ハンドラー」と呼ばれ、より抽象的なUIレベル（アプリケーションロジックを実装する場所）では「リスナー」と呼ばれます）。
EventHandlerは、すべてのUIコントロールのJavaFXに導入されています。一方、リスナーはプロパティなどのObservablesに借用されます。
EventHandlerは、監視可能なイベントとUIイベントを区別する方法です。
私はすべての情報を理解しようとしてきましたが、私は迷っています。 Delphi（Pascal）、C、C++、Javaを見てきましたが、何も明確ではありません。1か月後、これは問題です。私は完全に軌道に乗っていないので、教えてください...丁寧にお願いします。
Senderがキャッチャーを登録している限り、1つのイベント送信者、1つのキャッチャー。ファイル（処理コードは4つのダイアログボックスとは別のモジュールにあります）が変更されるたびに更新する必要がある4つのダイアログボックスがあります。昔ながらの方法でそれぞれを更新することを検討しましたが、Delphiイベントとメッセージ処理を調べました。どれどれ：
ファイルF（送信者）は読み取りを終了し、表示するデータとユーザーが操作するデータがあることをDialogs 1..4に通知する必要があります。最高は何ですか？
Dialogs 1..4をリスナーとして登録し、Senderが何らかの形でOnUpdatedDataEventをトリガーするようにしますか？
Dialogs 1..4がメッセージをキャッチすることを期待して、システム全体にメッセージを送信してみてください。
イベントは、メッセージングが行われない間、物事を結合し続けることに注意してください...そして、デバッグするのは苦痛です。
そして、コードのファイルブロックが4つのリスナー（ダイアログボックス）を登録できるようになるのだろうか？
私が見ているのは、カスケード呼び出しの可能性です。つまり、呼び出し元が1人のリスナーを呼び出し、そのリスナーがチェーンの最後に到達するまで次のリスナーを呼び出します。それが可能かどうかさえ疑問です。
例：
ファイルFは言語のリストです。これで、DialogBox 1はリストに何かを実行します（たとえば、新しい言語を追加します）。そのコンボボックスはFファイルを更新します。これにより、DataUpdatedEventがトリガーされます。 4つのダイアログボックスには、たとえば、ポップアップ時に言語リストを表示するTComboBoxが含まれています。 4つのボックスが変更を認識し、コンボボックスの内容を更新する必要があることをコンボボックスがどのように認識するかを心配せずに、新しく更新されたファイルでコンボボックスの内容を更新します。想定どおりに機能する場合、Senderパラメーターが引き継がれ、dataUpdateEventをトリガーしたダイアログボックスは既に更新されているため、バイパスされます。結局、if sender = selfの場合、次のイベントハンドラに進むと実装が簡単になります。
それは、アルツハイマー病を予防するために脳を鍛えたいからです。