Загалом, у Java існують слухачі та обробники подій.
Я маю на увазі, що використовую їх несвідомо, залежно від того, що доступне в API.
Моє питання полягає в тому, в якому випадку ми використовуємо слухачі, а в якому випадку - обробники подій?
Яка різниця між ними? Характеристика ??
Я шукав причини і не міг знайти належного пояснення для Java.
Відповіді:
Формально визначеної різниці між слухачами та обробниками немає. Деякі люди, напевно, будуть стверджувати, що вони взаємозамінні. Однак для мене вони мають дещо інше значення.
Слухач - це об’єкт, який передплачує події з джерела. Пор. модель спостерігача . Зазвичай у вас може бути багато слухачів, які підписуються на кожен тип подій, і вони додаються за допомогою addXyzListenerметодів.
Приклад:MouseListener в API Java.
Обробник - це об’єкт, який відповідає за обробку певних подій. Типовим сценарієм буде надання обробника для конкретної події / завдання як аргумент конструктору або встановлення обробника за допомогою setXyzHandlerметоду. Іншими словами, у вас зазвичай є один обробник для кожного типу події.
Приклад:MemoryHandler в API Java.
Основна відмінність - це асоціація
Взагалі кажучи, існує лише один центральний менеджер обробників, який керує всіма подіями, тоді як у випадку слухача кожна організація, яка хоче слухати, повинна буде керувати власною колекцією слухачів
Я бачу це так:
А слухач годинник для події звільнять. Наприклад, KeyListenerчекає KeyEvents, MessageListenerчекає надходження повідомлень у чергу тощо.
Оброблювач відповідає за справу з подією. Зазвичай слухачі та обробники йдуть рука об руку. Наприклад, KeyListener повідомляє ExitHandler, що «була натиснута буква Q», і обробник виконує логіку, таку як очищення ресурсів та витончений вихід із програми. Подібно ButtonClickListener повідомляє тому самому ExitHandler, що "клацнула кнопка виходу". Отже, у цьому випадку у вас є дві різні події, два різні слухачі, але один обробник.
Слухач - це об’єкт, про який повідомляється, коли відбувається подія, і він має 2 основні вимоги - 1 - він повинен бути зареєстрований в одному або декількох джерелах для отримання повідомлень про конкретні типи подій 2 - він повинен реалізовувати методи прийому та обробки ці повідомлення. Хендлер відповідає за справу з подіями.
Слухач слухає події, які є об'єктами значення даних, що описують подію. Коли подія сталася і порядок подій часто важливий. Натискання клавіші "0", після чого "1", відрізняється від "1" та "0".
Обробник обробляє складний об'єкт, наприклад, нове з'єднання Socket. Обробник може обробляти об'єкт протягом будь-якого періоду часу. Час створення та впорядкування об'єктів не так важливий. Підключення від client0 або client1 може відбуватися у будь-якому порядку.
Я думаю, що різниця незначна, тому що конкретний слухач теж є обробником подій або, принаймні, має метод, який можна вважати обробником подій. Тобто конкретний прослуховувач обробляє або керує реакцією на подію після отримання об’єкта події (з джерела події) з усією корисною інформацією про подію, яка щойно сталася (на джерелі події). Оскільки цей слухач повинен реалізувати інтерфейс xxxListener, який змушує його реалізувати принаймні один метод, який, у свою чергу, виконується об'єктом-джерелом події, коли подія відбувається, тому самого слухача можна вважати обробником, а точніше, методом інтерфейс Listener, реалізований об'єктом Listener, можна вважати реальним обробником подій. Тому я розглядаю обробник подій як просто код, який виконується у відповідь на подію. Це відрізняється від об'єкта слухача, який є елементом більш абстрактного поняття, такого як шаблон дизайну Observer. Це мій особистий погляд на тему.
Вони концептуально однакові - об’єкт, який виконує певну дію у відповідь на подію інтерфейсу користувача. Як правило, у Swing ці об'єкти називаються "обробниками" на рівні зовнішнього вигляду (для обробки подій віджетів низького рівня) та "слухачами" на більш абстрактному рівні інтерфейсу (де ви будете реалізовувати логіку свого додатка ).
EventHandler представлений в JavaFX для всіх елементів керування інтерфейсом. Тоді як слухач позичений для спостережуваних, таких як властивості.
EventHandler - це спосіб розрізнити спостережувані події та події інтерфейсу користувача.
Я намагався зрозуміти всю інформацію, і я загубився. Я розглядав Delphi (Pascal), C, C ++, java ... нічого не зрозуміло, отже, через місяць це проблема, як я бачу. Можливо, я зовсім не на шляху, тому, будь ласка, скажіть мені ... чемно, будь ласка.
Один відправник події, один ловець, якщо відправник реєструє ловця. У мене є 4 діалогові вікна, які потрібно оновлювати щоразу, коли змінюється файл (код обробки якого знаходиться в іншому модулі, ніж 4 діалогові вікна). Я розглядав можливість оновлення кожного по-старому, але потім переглянув події Delphi та обробку повідомлень. Подивимось:
Файл F (Відправник) закінчено читати, і він повинен повідомити діалогові вікна 1..4 про те, що зараз є дані для їх відображення та користувач, з яким можна пограти. Що найкраще?
Спробуйте зареєструвати діалогові вікна 1..4 як слухачі і змусити відправника якось увімкнути OnUpdatedDataEvent?
Спробуйте надіслати повідомлення по системі, сподіваючись, що діалогові вікна 1..4 його зрозуміють?
Зверніть увагу, що подія зберігає речі, пов’язані між собою, а обмін повідомленнями не робить ... і їх важко налагодити.
І мені цікаво, як блок файлів коду зможе зареєструвати 4 слухачів (діалогові вікна)?
Я розглядаю можливість каскадного дзвінка, тобто виклик викликає одного слухача, котрий дзвонить наступному ... до досягнення кінця ланцюжка. Мені навіть цікаво, чи можливо це взагалі?
Приклад:
Скажімо, Файл F - це список мов. Тепер DialogBox 1 робить щось у списку (додає нову мову, наприклад); що поле зі списком оновлює файл F; це, в свою чергу, запускає DataUpdatedEvent. 4 діалогові вікна містять, скажімо, TComboBoxes, які відображають список мов при їх появі. Я хочу, щоб 4 поля помітили зміну та оновили власний вміст комбінованого поля зі свіжооновленим Файлом ... не турбуючись про те, як комбіновані поля знають, що їм потрібно оновити їхній вміст. Якщо він працює так, як передбачалося, параметр відправника буде перенесено, а діалогове вікно, яке ініціювало dataUpdateEvent, буде обійдено, оскільки воно вже буде оновлено. Зрештою, якщо sender = self, то перехід до наступного обробника події повинен бути легким у реалізації.
Все це тому, що я хочу вправити свій мозок ... щоб запобігти хворобі Альцгеймера.
Це семантика.