В общих чертах java есть прослушиватели и обработчики событий.
Я имею в виду, что я использую их неосознанно, просто в зависимости от того, что доступно в API.
Мой вопрос: в каком случае мы используем прослушиватели, и в каком случае мы используем обработчики для событий?
Какая разница между ними? Характеристики??
Я искал причины, и я не мог найти правильное объяснение для Java.
Там нет формально определенной разницы между слушателями и обработчиками. Некоторые люди, вероятно, утверждают, что они взаимозаменяемы. Для меня, однако, они имеют немного другое значение.
Слушатель - это объект, который подписывается на события из источника. Ср образец наблюдателя. Обычно у вас может быть много подписчиков, подписывающихся на каждый тип события, и они добавляются через методы add XyzListener.
Пример: MouseListener в Java API.
Обработчик - это объект, который отвечает за обработку определенных событий. Типичным сценарием может быть предоставление обработчика для конкретного события/задачи в качестве аргумента для конструктора или установка обработчика с set XyzHandler метода set XyzHandler. Другими словами, у вас обычно есть один обработчик для каждого типа события.
Пример: MemoryHandler в API Java.
Самое основное отличие состоит в ассоциации
Вообще говоря, будет только один центральный диспетчер Handler, который управляет всеми событиями, в то время как в случае Listener каждый Entity, который хочет слушать, ему придется управлять собственной коллекцией слушателей.
Вот так я вижу:
A прослушиватель смотрит на событие, которое нужно уволить. Например, KeyListener ждет KeyEvents, MessageListener ожидает, что сообщения поступят в очередь и т.д.
Обработчик события несет ответственность за событие. Обычно слушатели и обработчики идут рука об руку. Например, KeyListener сообщает ExitHandler, что "была нажата буква Q", и обработчик выполняет логику, такую как очистка ресурсов и изящество из приложения. Similary ButtonClickListener сообщит тому же ExitHandler, что нажата кнопка "Выход". Итак, в этом случае у вас есть два разных события, два разных прослушивателя, но один обработчик.
Слушатель, прослушивает события, которые являются объектами значений данных, которые описывают событие. Когда событие произошло, и порядок событий часто важен. Нажатие клавиши "0", за которой следует "1", отличается от "1" и "0".
Обработчик, обрабатывает сложный объект, например. новое соединение сокета. Обработчик может обрабатывать объект в течение некоторого времени. Время создания и порядка объектов не так важно. Соединение с client0 или client1 может происходить в любом порядке.
Слушатель - это объект, который уведомляется о возникновении события и имеет два основных требования: 1 - он должен быть зарегистрирован в одном или нескольких источниках для получения уведомлений о конкретных типах событий 2 - он должен внедрять методы получения и обработки этих уведомлений. Обработчик отвечает за события.
Я думаю, что разница тонкая, потому что конкретный Listener также является обработчиком событий или, по крайней мере, имеет метод, который можно рассматривать как обработчик событий. То есть, конкретный Listener обрабатывает или управляет реакцией на событие после получения объекта события (из источника события) со всей полезной информацией о только что произошедшем событии (в источнике события). Поскольку этот Listener должен реализовать интерфейс xxxListener, который заставляет его реализовать хотя бы один метод, который в свою очередь выполняется объектом-источником события при возникновении события, поэтому сам Listener можно рассматривать как обработчик, а точнее - метод интерфейс Listener, реализованный объектом Listener, можно считать реальным обработчиком событий. Поэтому я рассматриваю обработчик событий как код, который выполняется в ответ на событие. Это отличается от объекта Listener, который является элементом более абстрактного понятия, такого как шаблон проектирования Observer. Это мое личное мнение по этому вопросу.
На мой взгляд, самое важное отличие заключается в том, что мы используем прослушиватели для каждого источника событий, в отличие от обработчика, который относится к типу события.
Они концептуально одно и то же - объект, который выполняет некоторые действия в ответ на событие пользовательского интерфейса. Как правило, в Swing эти объекты называются "обработчики" на уровне внешнего вида (для обработки событий виджетов низкого уровня) и "слушателей" на более абстрактном уровне пользовательского интерфейса (где вы будете внедрять свою логику приложения).
EventHandler представлен в JavaFX для всех элементов управления пользовательского интерфейса. Принимая во внимание, что Слушатель заимствован для Наблюдаемых, таких как свойства.
EventHandler - это способ различать наблюдаемые события и события ui.
Я пытался разобраться во всей информации, и я потерян. Я посмотрел на Delphi (Паскаль), C, C++, Java... ничего не ясно. Итак, через месяц, это проблема, как я ее вижу. Я могу быть совершенно не в курсе, поэтому, пожалуйста, скажите мне... вежливо, пожалуйста.
Один отправитель события, один перехватчик, пока отправитель регистрирует перехватчика. У меня есть 4 диалоговых окна, которые необходимо обновлять каждый раз, когда файл (код обработки которого находится в другом модуле, чем 4 диалоговых окна), изменяется. Я подумал об обновлении каждого по-старому, но потом я посмотрел на события Delphi и обработку сообщений. Давай посмотрим:
Файл F (Отправитель) закончил чтение и должен уведомить Диалоги 1..4 о том, что теперь есть данные для их отображения и пользователь для игры. Что лучше?
Попробуйте зарегистрировать диалоги 1..4 в качестве слушателей, и отправитель должен как-то вызвать OnUpdatedDataEvent?
Попробуйте отправить сообщение через систему, надеясь, что Dialogs 1..4 его поймает?
Обратите внимание, что событие связывает вещи, в то время как обмен сообщениями - нет... и их сложно отлаживать.
И мне интересно, как блок кода File сможет зарегистрировать 4 слушателя (диалоговые окна)?
То, на что я смотрю, - это возможность каскадного вызова, то есть вызывающий абонент вызывает одного слушателя, который вызывает следующего... пока он не достигнет конца цепочки. Мне даже интересно, возможно ли это вообще.
Пример:
Say File F - это список языков. Теперь DialogBox 1 что-то делает со списком (например, добавляет новый язык); это поле со списком обновляет F файл; это, в свою очередь, вызывает DataUpdatedEvent. 4 диалоговых окна содержат, скажем, TComboBox, которые отображают список языков, когда они всплывают. Я хочу, чтобы 4 поля отметили изменение и обновили содержимое своего собственного поля со списком недавно обновленного файла... не беспокоясь о том, как эти поля со списком знают, что им нужно обновить свое содержимое. Если он работает так, как предполагалось, параметр Sender будет перенесен, и диалоговое окно, которое вызвало dataUpdateEvent, будет пропущено, поскольку оно уже будет обновлено. В конце концов, если sender = self, то переход к следующему обработчику событий должен быть простым в реализации.
Все это потому, что я хочу тренировать свой мозг... для предотвращения болезни Альцгеймера, не очень успешно, я мог бы добавить.
Это семантика.
Типичный пример из реальной жизни - автомобиль, ожидающий, пока светофор покажет зеленый цвет, прежде чем автомобиль начнет движение. Автомобиль - это слушатель, а светофор - обработчик события.