| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Как лучше реализовывать интерфейс обраб. событий? |
| Автор: 604 15.4.2005, 14:21 | ||||
| Как лучше реализовывать интерфейс обраб. событий? В классе который содержит компоненты на которые вешаются события или в отдельном? я вижу 2 варианта: Тут мы не содаем доп. классов но если много слушателей тогда приходится строить кучу условий.
Тут мы избавились от условий но получаем много анонимных классов (Возможно загрузка класса более ресурсоёмкая задача?)
Собственно теперь вопрос! Как делать правильно, и какой из вариантов лучше? Или нужно совсем иначе? |
| Автор: batigoal 15.4.2005, 15:35 | ||||
Попробовал провести тест.
Результаты почти идентичны: Однократное нажатие каждой кнопки: 6940 против 6860. Потом попробовал эмулировать трехкратное нажатие (как в коде): 20900 против 20590. Можно было бы оптимизировать поиск в массиве, но не стал - ведь в общем случае у тебя не массив, а именно перебор. |
| Автор: AntonSaburov 15.4.2005, 17:36 |
| IMHO надо делать так, чтобы было удобно читать, править и расширять. Общие принципы обычно имеют критерии как и для обычного ООП. |
| Автор: Domestic Cat 15.4.2005, 18:20 |
| Есть еще Command паттерн, правда придется сабклассить каждый баттон. Можно листенером сделать не сам класс с гуем, а отдельный делегат. |
| Автор: NotGonnaGetUs 17.4.2005, 13:45 | ||||
Если речь идёт за тот "Комманд паттерн", который описан в http://forum.vingrad.ru/index.php?showtopic=41784&st=30, то лучше забыть о нём. Хотя бы потому, что листенер на бутон всё равно вешается, и этот листенер есть сам бутон. "Нормальный" комманд паттерн предполагает, что у нас есть набор однотипных заданий (комманд, классов с общим интерфейсом) и исполнитель этих задний. На практике всё можно изуродывать под конретную задачу. Возмём тот же ГУИ с кнопочками. При инициализации панели создаём класс контроллер. Каждому активному объекту вешаем листенер, который делегирует событие контроллеру.
Следующий шаг это вручение каждому активного компоненту уникального ID и составление таблицы "ID - Комманда1, Комманда2...", что бы изменение логики можно было производить правкой файла пропертисов или xml, не меняя код инициализации. Можно строить один большой контроллер, можно строить иерархию контроллеров по типу того, как сделано в маверике. Короче говоря простор для творчества большой з.ы. сорри, пример на ходу придумывал |
| Автор: batigoal 17.4.2005, 14:05 | ||
А надо ли оно нам? Интерфейс приложениия меняется не так уж часто... Имхо, не стоит усложнять код. |
| Автор: NotGonnaGetUs 17.4.2005, 14:46 |
| Вам наверное не надо |
| Автор: Domestic Cat 17.4.2005, 18:05 | ||
Ты извини, это не код... При пятом нажатии на кнопку будет выполнено 5 раз SendMailTo.execute и 5 раз Command.execute. У анонимных классов доступа к локальным переменным в коде нет . И т п. |
| Автор: NotGonnaGetUs 19.4.2005, 10:33 | ||||
Есть такое, my bad. Поправил. Как вариант можно описать требования к ГУИ и реализовать его выше описанными способами. Будет наглядно и полезно |
| Автор: Гость_604 22.4.2005, 09:51 |
| Всем спасибо! Насколько я понял, ничего плохого в моем коде нет, так что оставлю все как есть. |
| Автор: Zandr 22.4.2005, 11:58 | ||
В каком смысле? Пример хочу |
| Автор: batigoal 22.4.2005, 12:22 | ||
Вроде есть... Добавлено @ 12:23 Если она final |
| Автор: Zandr 22.4.2005, 12:29 |
| Собсна об этом я и писал http://forum.vingrad.ru/index.php?showtopic=48585&view=findpost&p=387904 |