• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Слухачі подій

Подієва модель в JFC

Тепер розглянемо безпосередньо подієву модель Java.

По-перше, треба відмітити, що вона повністю реалізована засобами стандартної бібліотеки Java ( JFC - Java Foundation Classes).

По-друге, слід сказати, що подієва модель, у свою чергу, використовується в інших програмних парадигмах JFC як засіб реалізації або складова частина. До них відносяться MVC -архітектура (від Model - View - Controller), Java Beans і інші поняття.

Отже знати основи подієвої моделі Java дуже важливо.

Ми не розглядатимемо її повністю, в усіх аспектах, а лише з точки зору реального використання. Внутрішня реалізація подієвої моделі і ряд нюансів залишаться нерозглянутими. Базові класи, на яких заснована подієва модель, знаходяться в пакеті java.util .

Власне об'єкт-подія (event state object) це - об'єкт класу, породженого від класу EventObject . Як вказувалося, цей об'єкт є носієм параметрів події, що сталася. Розглянемо документацію по EventObject .

З неї можна зробити висновок, що мінімальний набір параметрів події - це об'єкт джерело події, яке може бути отримане методом public Object getSource() класу EventObject . Оскільки EventObject є базовим класом для усіх інших класів-подій, то цей метод присутній в усіх цих класах.

Другий вивід, який можна зробити з документації, це само наявність об'єкту - джерела події. Тобто будь-яка подія в JFC завжди породжується деяким об'єктом, якогось класу.

Отже, ми маємо дві дійові особи - об'єкт-джерело і об'єкт-подія . Третьою діючою особою є "слухач" (лісенер, listener ).

Із слухачами подій ми вже зустрічалися в прикладах. Зараз розберемо це поняття детальніше.

Слухачем може бути об'єкт будь-якого класу, що задовольняє певному інтерфейсу - інтерфейсу-слухачеві. Усі інтерфейси-слухачі породжені від базового інтерфейсу EventListener . Якщо ми подивимося документацію по цьому інтерфейсу, то побачимо, що він не має ніяких методів. Це означає, що усі слухачі мають різні методи для прослуховування подій.

Усі інтерфейси-слухачі (за рідкісним виключенням) мають імена XXXListener . Тут під XXX мається на увазі деяке ім'я події. Наприклад, ActionListener або AWTEventListener, і так далі

Об'єкти - джерела подій мають бути об'єктами класу, який має методи для реєстрації слухача addXXXListener і відключення слухача removeXXXListener . Відповідно, кожен конкретний клас - джерело подій дозволяє підключати до об'єкту-джерела тільки слухачі певних типів, для яких в класі є методи підключення addXXXListener .

Робота моделі подій заснована на тому, що при настанні якої-небудь події об'єкт-джерело викликає певні методи інтерфейсу XXXListener для усіх об'єктів-слухачів, що реєструються.

Слухачі представлені в JFC у вигляді інтерфейсів, а не класів тому, що по сенсу вони самі по собі нічого не повинні робити. Вони надають нам можливість написати програмний код, який виконуватиметься при настанні якої-небудь події.

Розглянемо для прикладу простий інтерфейс-слухач ActionListener з пакету java.awt.event . Він містить єдиний метод

Цей метод викликається, коли виконана деяка дія.

Що це за дію і коли воно відбувається, самим цим інтерфейсом не визначено. Але у ряді класів є методи addActionListener, які дозволяють зареєструвати слухача типу ActionListener для прослуховування тих або інших подій. Що це за події із змістовної точки зору (тобто в яких випадках вони відбуваються) - це описано в класі, що має метод addActionListener .

По розглянутих прикладах ми знаємо, що для об'єкту класу JButton можна зареєструвати слухача типу ActionListener . Звернемося до документації по класу JButton .

У документації ми побачимо, що в самому класі JButton метод addActionListener не визначений, але в його базовому класі AbstractButton такий метод є.

На жаль, в документації по цьому методу не описано, коли викликається метод actionPerformed інтерфейсу ActionListener і можна лише здогадатися, що саме при натисненні цієї кнопки. Документація лише посилає нас до відповідного керівництва How to Use Buttons, Check Boxes, and Radio Buttons .

Згадаємо розглянуті раніше приклади. Так в програмі Dialog4.java присутній такий фрагмент.

У цьому фрагменті використаний апарат анонімних класів для скорочення об'єму коду. Реалізуємо цей фрагмент в іншому еквівалентному виді, розписавши детально кожен етап.

У такому варіанті наочніше видно, що відбуватиметься. При натисненні на кнопку об'єкт btn згенерує подію ActionEvent, тобто фактично він створить об'єкт класу ActionEvent і викличе метод actionPerformed з цим об'єктом як параметр для усіх слухачів, що реєструються.

Таким чином, в потрібний момент буде викликаний метод actionPerformed, який ми запрограмували в класі ButtonListener1 . В нашому прикладі цей метод ніяк не використовує інформацію з об'єкту події (параметр e ). В даному випадку вона не потрібна. Усе, що треба, нам вже відомо - сталося натиснення на кнопку btn .

Уявимо собі іншу ситуацію. Нехай у нас в програмі декілька кнопок. В цьому випадку у нас є вибір з двох варіантів реалізації реакції на натиснення кнопок. Перший полягає в створенні для кожної кнопки окремого класу, окремого об'єкту цього класу і реалізації в кожному з методів actionPerformed необхідних дій. Тоді, як і в прикладі, нам не буде потрібно інформацію з параметра методу actionPerformed .

Другий варіант полягає в створенні одного класу-слухача, одного об'єкту-слухача і в програмуванні усіх дій у рамках одного методу actionPerformed . Ось тут нам обов'язково буде потрібно параметр цього методу, оскільки тільки з його допомогою ми зможемо дізнатися, яка саме кнопка була натиснута.

Приведемо в шаблонному виді реалізацію цього варіанту

Обидва варіанти є прийнятними і в кожній конкретній ситуації можна вибрати один з них.

· Відмітимо, що, коли б не апарат анонімних класів, який дає можливість записати реалізацію слухачів в компактній формі, то другий варіант був би прийнятнішим.

· Цей приклад демонструє ще одну особливість слухачів. Ми не лише можемо до одного об'єкту - джерелу подій підключити ряд слухачів, але і одного слухача підключити до декількох об'єктів - джерел подій.

Інтерфейс ActionListener дуже простий, він містить всього один метод. Але існують і складніші інтерфейси слухачів, наприклад, WindowListener, з яким ми теж вже зустрічалися в прикладах.

Звернемося знову до документації. Інтерфейс WindowListener має такі методи.

Викликається при відкритті вікна (коли воно стає видимим вперше).

Викликається при закритті вікна.

Викликається при активізації вікна.

Викликається при деактивизации вікна.

Викликається при спробі закрити вікно.

Викликається при згортанні вікна в іконку на панелі.

Викликається при розгортанні вікна з іконки в нормальний стан.

Як бачимо тут досить багато методів. Вони викликаються в певних ситуаціях в деякій послідовності. Так, наприклад, при згортанні вікна в іконку буде викликаний спочатку метод windowDeactivated, потім windowIconified .

Зазвичай для інтерфейсів-слухачів, що мають більш за один метод, створюються допоміжні класи-адаптери. У цих класах усе, або більшість методів цього інтерфейсу реалізовані і зазвичай нічого не виконують.

Це зроблено з практичних міркувань. Якщо створювати клас, що задовольняє, скажімо, інтерфейсу WindowListener, то в нім треба реалізувати усі методи цього інтерфейсу. В той час, як найчастіше нас цікавить один або декілька методів цього інтерфейсу. Тут на допомогу приходять класи-адаптери. Свій клас можна успадкувати від класу-адаптера і перевизначити в нім потрібні методи.

Саме так ми і робили в прикладах для організації завершення застосування при закритті головного вікна.

Тут для побудови анонімного класу використаний не інтерфейс WindowListener, як ми робили при роботі з ActionListener, а клас-адаптер WindowAdapter . В нім усі методи інтерфейсу WindowListener реалізовані, і ми можемо перевизначити тільки один метод, що цікавить нас, - windowClosing .

Читайте також:

1. Алгебра випадкових подій
2. Алгебра подій
3. Безвілля, його заподій і переборення.
4. Види випадкових подій
5. Визначення базисних подій. Ідентифікація ризику.
6. Виникнення Народного Руху України за перебудову. Роль цієї організації у розвиткові політичних подій в республіці протягом 1989-1991 р.
7. Витрати від надзвичайних подій
8. Виявлення, оцінка та зменшення ризиків небезпечних подій. Облік і аналіз показників охорони праці
9. Втручання тоталітарних держав до подій в Іспанії
10. Дайте аналіз розвитку революційних подій на Україні в 1905-1907 рр.
11. Дайте аналіз розвитку революційних подій на Україні в 1905-1907 рр.
12. Дебітори –це юридичні та фізичні особи, які внаслідок минулих подій, заборгували підприємству певні суми грошових коштів, їх еквівалентів та інших активів.

Переглядів: 1137