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

• внутренние классы
• анонимные классы
• фабрика событий
• диспечеризация

Анонимные классы с диспечеризацией мне как-то сразу не приглянулись. Хотя черт его знает, как на самом деле...
Было бы здорово, если расскажете о плюсах и минусах той или иной техники (вполне вероятно, что я чего-то по незнанию упустил).

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

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

А что понимается под "диспетчеризация"? События от контролов всегда доставляются зарегистрированным лисенерам (хендлерам) через event dispatching thread (EDT).

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

Спасибо тем, кто откликнулся.

2Skipy,
Про фабрику событий я представлял себе так. Существует один класс, например, ListenerFactory (можно даже его сделать Singleton) и в нем методы такие как

тогда присоединять слушатели было бы удобно

как минус представляется мне то, что из самой ListenerFactory фиг разберешь куда и к чему эти listeners относятся. Объяснил я похоже криво, но х8m6 похоже тоже самое через FormController делает.

С внутренними классами понятно, удобно. А с анонимными разве не возникает неразберихи?

Добавлено через 10 минут и 4 секунды
2COVD, 
про диспечеризацию я имел в виду следующее, вешается один и тот же слушатель, например на кнопки button1 и button2. А потом смотрим

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

P.S. На данный момент меня интересует техника написания слушателей для standalone приложений.

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

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

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

Впрочем, последний случай больше располагает к применению JMS.

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

У каждого контрола вроде есть actionName. В таком случае можно использовать: Map<String, Listener> и все будет пучком с точки зрения расширяемости. Тут только важно не запутаться со строковыми значениями.undo и слушатели - это из разных эпопей строки. Чтоб организовать undo нужно реализовать Команду, которая будет деграться слушателем, т.о. слушатель будет один, но в нем может быть коллекция выполненных Команд (это как пример реализации). По-моему отличный вариант. Единственное - нужно подумать как сделать так, чтоб этот FormController не был зависим от Swing-классов, т.е. слушатели все равно будут, но они должны готовить запрос и делегировать выполнение этому FormController'у.

Добавлено через 6 минут и 7 секунд
Вот это сообщение так же советовал бы прочитать.

Это сообщение отредактировал(а) Старовъръ - 25.8.2010, 00:41