Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java: GUI и Java FX приложения > Слушатели в профессиональных SWING-приложениях

Автор: mstalker26 23.8.2010, 21:55

Собственно возник вопрос: как организовывают технику написания слушателей (listeners) в профессиональных (и что более важно в больших) swing-приложениях. Хотелось бы чтобы оставляли комментарии те, кто действительно работал с этим на практике. Я только в теории   , поэтому и стало интересно. Мне на ум пришли следующие варианты: внутренние классы анонимные классы фабрика событий диспечеризация Анонимные классы с диспечеризацией мне как-то сразу не приглянулись. Хотя черт его знает, как на самом деле... Было бы здорово, если расскажете о плюсах и минусах той или иной техники (вполне вероятно, что я чего-то по незнанию упустил).

Автор: Skipy 24.8.2010, 10:22

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

Автор: x8m6 24.8.2010, 15:58

Если на форме большое кол-во виджетов, то лучше выносить всех слушателей в отдельный класс и называть его FormController. В нем можно и логику сразу зашить. Так логика будет отделена от вида. В больших Swing приложениях здорово помогает.

Автор: COVD 24.8.2010, 17:14

А что понимается под "диспетчеризация"? События от контролов всегда доставляются зарегистрированным лисенерам (хендлерам) через event dispatching thread (EDT). В приложении может быть возможность открывать одновременно несколько одинаковых окон. Например, пользователь наблюдает одну и ту же таблицу, но отсортированную по-разному. События могут быть как локальными для окна, так и уровня всего приложения. Пользователь удаляет строку в таблице -> следует запрос на сервер -> с сервера приходит подтверждение -> все открытые окна, отображающие таблицу, обновляются (возможно, у всех пользователей). В приложении может быть общая шина (очередь) для такого рода событий.

Автор: mstalker26 24.8.2010, 17:17

Спасибо тем, кто откликнулся. 2Skipy, Про фабрику событий я представлял себе так. Существует один класс, например, ListenerFactory (можно даже его сделать Singleton) и в нем методы такие как Код public WindowListener getWindowL() {     return new WindowListener() {         public void windowClosing(WindowEvent we) {             //смотрим что за окно и чего-нибудь с ним делаем .... тогда присоединять слушатели было бы удобно Код addWindowListener(factory.getWindowL()); как минус представляется мне то, что из самой ListenerFactory фиг разберешь куда и к чему эти listeners относятся. Объяснил я похоже криво, но х8m6 похоже тоже самое через FormController делает. С внутренними классами понятно, удобно. А с анонимными разве не возникает неразберихи? Добавлено через 10 минут и 4 секунды 2COVD,  про диспечеризацию я имел в виду следующее, вешается один и тот же слушатель, например на кнопки button1 и button2. А потом смотрим Код public void actionPerformed(ActionEvent ae) {     if(ae.getSource() == button1)         //чего-нибудь вытворяем     else(ae.getSource() == button2)         //ничего не вытворяем :) но как skipy заметил, если слушателей и источников наберется н-ное количество, можно будет застрелиться, чтобы не мучаться. P.S. На данный момент меня интересует техника написания слушателей для standalone приложений. Вроде как выходит внутренние классы и отдельный класс со слушателями подходят больше всего?

Автор: COVD 24.8.2010, 17:35

Цитата вешается один и тот же слушатель Я так делал, но у меня не было случая, когда в одном окне 50 кнопок.

Автор: jk1 24.8.2010, 21:43

Цитата Вроде как выходит внутренние классы и отдельный класс со слушателями подходят больше всего?  Подход с фабрикой хорош тогда, когда события и обработчики надо регистрировать (например для операций типа Undo) или организовывать сложные разветвленные цепочки обмена событиями и сообщениями. Впрочем, последний случай больше располагает к применению JMS.

Автор: mstalker26 25.8.2010, 00:20

Похоже на то, что самые активные отписались в этой теме. Всем спасибо за ответы. *ушел переваривать информацию*

Автор: Старовъръ 25.8.2010, 00:40

Цитата Четвертый - будут проблемы с расширяемостью и поддержкой приложения. Я посмотрю на Ваш метод диспетчеризации, когда у Вас будет хотя бы полсотни источников и слушателей У каждого контрола вроде есть actionName. В таком случае можно использовать: Map<String, Listener> и все будет пучком с точки зрения расширяемости. Тут только важно не запутаться со строковыми значениями. Цитата Подход с фабрикой хорош тогда, когда события и обработчики надо регистрировать (например для операций типа Undo) undo и слушатели - это из разных эпопей строки. Чтоб организовать undo нужно реализовать Команду, которая будет деграться слушателем, т.о. слушатель будет один, но в нем может быть коллекция выполненных Команд (это как пример реализации).  Цитата Если на форме большое кол-во виджетов, то лучше выносить всех слушателей в отдельный класс и называть его FormController. В нем можно и логику сразу зашить. Так логика будет отделена от вида. В больших Swing приложениях здорово помогает.  По-моему отличный вариант. Единственное - нужно подумать как сделать так, чтоб этот FormController не был зависим от Swing-классов, т.е. слушатели все равно будут, но они должны готовить запрос и делегировать выполнение этому FormController'у. Добавлено через 6 минут и 7 секунд Вот http://javatalks.ru/sutra86469.php#86469 сообщение так же советовал бы прочитать.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)