Javaのイベントリスナーとハンドラーの違いは何ですか？

Javaの一般的な用語では、イベントのリスナーとハンドラーがあります。
つまり、APIで利用可能なものだけを、無意識のうちに使用します。

私の質問は、どのような場合にリスナーを使用し、どのような場合にイベントのハンドラーを使用するのかということです。

それらの違いは何ですか？特徴??

理由を検索しましたが、Javaの適切な説明が見つかりませんでした。

リスナーとハンドラーの間に正式に定義された違いはありません。一部の人々はおそらくそれらが交換可能であると主張するでしょう。しかし、私にとっては、それらの意味は少し異なります。

リスナーは、ソースからのイベントをサブスクライブするオブジェクトです。Cf. Observerパターン。通常、イベントの種類ごとに多くのリスナーをサブスクライブさせることができ、それらはメソッドを介して追加されaddXyzListenerます。

例：MouseListener Java APIのインチ

ハンドラーは、特定のイベントの処理を担当するオブジェクトです。典型的なシナリオは、コンストラクターへの引数として特定のイベント/タスクのハンドラーを提供するか、メソッドを介してハンドラーを設定するsetXyzHandlerことです。つまり、通常、イベントの種類ごとに1つのハンドラーがあります。

例：MemoryHandler Java APIのインチ

最も基本的な違いは関連付けです

• リスナーはイベントソースに関連付けられています（例：キーボード）
• ハンドラーはイベントに関連付けられています（例：キーダウン）

一般的に、すべてのイベントを管理する中央のハンドラーマネージャーは1つだけですが、リスナーの場合、リッスンする各エンティティは、独自のリスナーのコレクションを管理する必要があります。

これは私がそれを見る方法です：

リスナーが解雇されるイベントを監視します。たとえば、KeyListenerKeyEventsをMessageListener待機したり、メッセージがキューに到着するのを待機したりします。

ハンドラーはイベントの処理を担当します。通常、リスナーとハンドラーは密接に関連しています。たとえば、KeyListenerはExitHandlerに「文字Qが押された」ことを通知し、ハンドラーはリソースのクリーンアップやアプリケーションの正常な終了などのロジックを実行します。同様に、ButtonClickListenerは、同じExitHandlerに「Exitボタンがクリックされた」ことを通知します。したがって、この場合、2つの異なるイベント、2つの異なるリスナー、ただし1つのハンドラーがあります。

リスナーは、イベントが発生したときに通知されるオブジェクトであり、2つの主要な要件があります。1-特定のタイプのイベントに関する通知を受信するには、1つ以上のソースに登録されている必要があります。2-受信および処理するメソッドを実装する必要があります。これらの通知。ハンドラーはイベントの処理を担当します。

リスナーは、イベントを説明するデータ値オブジェクトであるイベントをリッスンします。イベントが発生したとき、およびイベントの順序が重要になることがよくあります。キー「0」に続いて「1」を押すことは、「1」および「0」とは異なります。

ハンドラーは、新しいソケット接続などの複雑なオブジェクトを処理します。ハンドラーは、オブジェクトを任意の時間処理する場合があります。オブジェクトの作成と順序付けの時間はそれほど重要ではありません。client0またはclient1からの接続は、任意の順序で発生する可能性があります。

具体的なリスナーもイベントハンドラーであるか、少なくともイベントハンドラーと見なすことができるメソッドがあるため、違いは微妙だと思います。つまり、具体的なリスナーは、（イベントソースから）発生したばかりのイベントに関するすべての有用な情報を含むイベントオブジェクトを（イベントソースから）受信した後、イベントへの反応を処理または管理します。このリスナーは、イベントが発生したときにイベントソースオブジェクトによって順番に実行される少なくとも1つのメソッドを実装するように強制するxxxListenerインターフェイスを実装する必要があるため、リスナー自体をハンドラー、より正確には、 Listenerオブジェクトによって実装されたListenerインターフェースは、実際のイベントハンドラーと見なすことができます。したがって、イベントハンドラーは、イベントに反応して実行されるコードと見なします。これは、オブザーバーデザインパターンなどのより抽象的な概念の要素であるリスナーオブジェクトとは異なります。これは私の個人的な主題の見方です。

私の考えでは、最も重要な違いは、イベントタイプごとのハンドラーとは対照的に、イベントのソースごとにリスナーを使用するという事実です。

それらは概念的に同じものです-UIイベントに応答して何らかのアクションを実行するオブジェクトです。一般に、Swingでは、これらのオブジェクトはルックアンドフィールレベル（低レベルのウィジェットイベントを処理するため）では「ハンドラー」と呼ばれ、より抽象的なUIレベル（アプリケーションロジックを実装する場所）では「リスナー」と呼ばれます。 ）。

EventHandlerは、すべてのUIコントロールのJavaFXに導入されています。一方、リスナーはプロパティなどのオブザーバブルのために借用されます。

EventHandlerは、監視可能なイベントとuiイベントを区別する方法です。

私はすべての情報を理解しようとしてきましたが、迷子になっています。Delphi（Pascal）、C、C ++、javaを調べましたが、明確なことは何もありません。1か月後、これが問題になります。私は完全に軌道に乗っていないかもしれないので、教えてください...丁寧にお願いします。

送信者がキャッチャーを登録している限り、1つのイベント送信者と1つのキャッチャー。ファイル（処理コードが4つのダイアログボックスとは別のモジュールにある）が変更されるたびに更新する必要がある4つのダイアログボックスがあります。昔ながらの方法でそれぞれを更新することを検討しましたが、次にDelphiのイベントとメッセージ処理を調べました。どれどれ：

ファイルF（送信者）は読み取りを終了し、ダイアログ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の場合、次のイベントハンドラーに進むのは簡単に実装できるはずです。

それはすべて、脳を鍛えたいからです...アルツハイマー病を予防するために、うまくいかないかもしれません。

それは意味論です。

• リスナーはインターフェースです。
• Adapterは、特定のインターフェースを実装し、そのメソッドに空の実装を提供するクラスです。これは、インターフェイスのすべてのメソッドを実装する必要がない場合に役立ちます。
• ハンドラーは、いくつかのインターフェースを実装するか、呼び出しをいくつかのインターフェースに委任します。