В чем разница между прослушивателями и обработчиками событий в Java?

Question

В общих чертах Java, есть слушатели и обработчики событий.
Я имею в виду, что я использую их по незнанию, просто в зависимости от того, что доступно в API.

У меня вопрос: в каком случае мы используем слушателей и в каких случаях мы используем обработчики событий?

Какая разница между ними? Характеристики ??

Я искал причины и не мог найти правильное объяснение Java.

Answer 1

Нет формально определенной разницы между слушателями и обработчиками. Некоторые люди, вероятно, утверждают, что они взаимозаменяемы. Для меня, однако, они имеют немного другое значение.

Слушатель - это объект, который подписывается на события из источника. Ср образец наблюдателя . Обычно вы можете иметь много подписчиков, подписывающихся на каждый тип события, и они являются добавленными - <b>add</b>XyzListener методами.

Пример: MouseListener в Java API.

Обработчик - это объект, который отвечает за обработку определенных событий. Типичным сценарием будет предоставление обработчика для конкретного события / задачи в качестве аргумента для конструктора или установка обработчика с помощью метода <b>set</b>XyzHandler. Другими словами, у вас обычно есть один обработчик для каждого типа события.

Пример: MemoryHandler в Java API.

Answer 2

Самое основное отличие - это ассоциация

• Слушатель связан с Источник события (Пример: клавиатура)
• Обработчик связан с Событием (Пример: keydown)

Вообще говоря, будет только один центральный диспетчер обработчиков, который управляет всеми событиями, в то время как в случае прослушивателя каждая сущность, которая хочет слушать, должна будет управлять своей собственной коллекцией слушателей

Answer 3

Вот как я это вижу:

A слушатель наблюдает за событием, которое должно быть запущено. Например, KeyListener ожидает KeyEvents, MessageListener ожидает поступления сообщений в очередь и т. Д.

Обработчик отвечает за обработку события. Обычно слушатели и обработчики идут рука об руку. Например, KeyListener сообщает ExitHandler, что «нажата буква Q», и обработчик выполняет логику, такую ​​как очистка ресурсов и корректный выход из приложения. Аналогично ButtonClickListener сообщит тому же ExitHandler, что «была нажата кнопка выхода». Итак, в этом случае у вас два разных события, два разных слушателя, но один обработчик.

Answer 4

Слушатель, слушает события, которые являются объектами значений данных, которые описывают событие.Когда произошло событие, и порядок событий часто важен.Нажатие клавиши «0», за которым следует «1», отличается от «1» и «0».

Обработчик обрабатывает сложный объект, например, новое соединение Socket.Обработчик может обработать объект за любой промежуток времени.Время создания объекта и порядок не так важны.Соединение с client0 или client1 может происходить в любом порядке.

Answer 5

На мой взгляд, наиболее важным отличием является то, что мы используем прослушиватели для источника события, в отличие от обработчика, который зависит от типа события.

Answer 6

Я думаю, что разница невелика, потому что конкретный Слушатель тоже является обработчиком событий или, по крайней мере, имеет метод, который можно считать обработчиком событий. То есть конкретный прослушиватель обрабатывает или управляет реакцией на событие после получения объекта события (из источника-события) со всей полезной информацией о только что произошедшем событии (в источнике-событии). Поскольку этот прослушиватель должен реализовать интерфейс xxxListener, который вынуждает его реализовать по крайней мере один метод, который, в свою очередь, выполняется объектом источника события при возникновении события, поэтому сам прослушиватель можно считать обработчиком, а точнее, методом интерфейс Listener, реализованный объектом Listener, можно считать реальным обработчиком событий. Поэтому я рассматриваю обработчик событий как просто код, который выполняется в ответ на событие. Это отличается от объекта Listener, который является элементом более абстрактной концепции, такой как шаблон проектирования Observer. Это мой личный взгляд на предмет.

Answer 7

Слушатель - это объект, который уведомляется, когда происходит событие, и он имеет 2 основных требования: 1 - он должен быть зарегистрирован в одном или нескольких источниках для получения уведомлений о конкретных типах событий 2 - он должен реализовывать методы для получения и обработки этих уведомлений. Обработчик отвечает за обработку событий.

Answer 8

Они концептуально одно и то же - объект, который выполняет какое-то действие в ответ на событие пользовательского интерфейса.Обычно в Swing эти объекты называются «обработчиками» на уровне внешнего вида (для обработки низкоуровневых событий виджетов) и «слушателями» на более абстрактном уровне пользовательского интерфейса (где вы будете реализовывать логику своего приложения).).

Answer 9

Я пытался разобраться во всей информации, и я потерян. Я посмотрел на Delphi (Pascal), C, C ++, Java ... ничего не ясно. Итак, через месяц это проблема, как я ее вижу. Я могу быть совершенно не в курсе, поэтому, пожалуйста, скажите мне ... вежливо, пожалуйста.

Один отправитель события, один перехватчик, если отправитель регистрирует перехватчик. У меня есть 4 диалоговых окна, которые необходимо обновлять каждый раз, когда файл (код обработки которого находится в другом модуле, чем 4 диалоговых окна), изменяется. Я подумал об обновлении каждого по-старому, но потом я посмотрел на события Delphi и обработку сообщений. Посмотрим:

Файл F (Отправитель) завершил чтение и должен уведомить диалоги 1..4 о том, что теперь есть данные для их отображения и пользователь, с которым можно поиграть. Что лучше?

Попробуйте зарегистрировать Dialogs 1..4 в качестве слушателей, и отправитель как-нибудь вызовет OnUpdatedDataEvent?

Попробуйте отправить сообщение через систему, надеясь, что Dialogs 1..4 его поймает?

Обратите внимание, что событие связывает вещи, в то время как обмен сообщениями этого не делает ... и является трудной для отладки.

И мне интересно, как блок кода File сможет зарегистрировать 4 слушателя (диалоговые окна)?

То, на что я обращаю внимание, - это возможность каскадного вызова, то есть вызывающий абонент вызывает одного слушателя, который вызывает следующего ... пока он не достигнет конца цепочки. Мне даже интересно, возможно ли это вообще.

Пример:

Say File F - это список языков. Теперь DialogBox 1 что-то делает со списком (например, добавляет новый язык); это поле со списком обновляет F-файл; это, в свою очередь, вызывает DataUpdatedEvent. 4 диалоговых окна содержат, скажем, TComboBox, которые отображают список языков, когда они всплывают. Я хочу, чтобы 4 поля отметили изменение и обновили содержимое своего собственного поля со списком недавно обновленного файла ... не беспокоясь о том, как эти поля со списком знают, что им нужно обновить свое содержимое. Если он работает так, как предполагалось, параметр Sender будет перенесен, и диалоговое окно, которое вызвало dataUpdateEvent, будет пропущено, поскольку оно уже будет обновлено. В конце концов, если sender = self, то переход к следующему обработчику событий должен быть простым в реализации.

Все это потому, что я хочу тренировать свой мозг ... для предотвращения болезни Альцгеймера, не очень успешно, я мог бы добавить.

Answer 10

EventHandler представлен в JavaFX для всех элементов управления пользовательского интерфейса.Принимая во внимание, что слушатель заимствован для наблюдаемых, таких как свойства.

EventHandler - это способ различить наблюдаемые события и события пользовательского интерфейса.