Java - Должны ли ActionListeners, KeyListeners и т.д. всегда объявляться во внутренних классах?

Question

Во всех примерах исходного кода Java, которые я видел, слушатели всегда объявлялись во внутренних классах.

Почему - в чем причина кодирования подобных классов вместо наличия слушателей?в их отдельном * .java файле \ class?

Будет ли иметь отдельные классы для слушателей плохой дизайн?

Если это не плохой дизайн \ оскорбительное нарушение, может кто-нибудь опубликоватькороткий пример, демонстрирующий, как это реализовать?

Спасибо за чтение.

Редактирование \ Обновление - 10.8.2010: Спасибо всем, кто нашел время, чтобы ответить.Много полезных моментов для рассмотрения.Прочитав все ответы, я думаю, что, если нет веских причин поступать иначе, лучше и проще объявить слушателей внутренними классами.

Извиняюсь, что не возвращаюсь к этому вопросу раньше, но я неу меня всегда есть столько времени для кодирования, сколько я хотел бы: - (

Счастливое кодирование.

Answer 1

Уважительные причины для использования внутренних классов:

• Избегает добавления дополнительных классов верхнего уровня в пространство имен вашего пакета
• Сохраняет код локально инкапсулированным (например, в компоненте, который требует событие)поведение обработки)
• статические внутренние классы работают хорошо, когда им не требуется доступ к полям включающего класса

Возможные причины использования классов верхнего уровня:

• У вас есть специальный тип слушателя, который, как вы ожидаете, будет использоваться внешними пакетами или является частью вашего API (например, в самой библиотеке классов Java)
• Слушатель используется во многих местах и ​​не являетсялогически специфичен для любого из множества возможных включающих классов

Короче говоря: внутренние классы обычно предпочтительнее, но если у вас есть веские причины, то вместо этого может быть вполне разумно создавать классы верхнего уровня.

Answer 2

В этом ответе обсуждаются компромиссы разных способов.

Основной ответ заключается в том, что код графического интерфейса в программе, как правило, довольно тесно переплетен и обычно не разделяется между программами. Выполнение внутренних классов (особенно если вы принимаете способ, который я предлагаю в связанном ответе выше), позволяет структурировать код GUI таким образом, чтобы его можно было обслуживать, одновременно признавая, что графический интерфейс тесно связан.

Answer 3

Нет, я не думаю, что они всегда должны быть внутренними классами.Это означает, что сам пользовательский интерфейс всегда знает, как сделать лучший выбор слушателя.

Еще один способ взглянуть на это может состоять в том, что слушатели вводятся в пользовательский интерфейс.Возможно, они предоставляются Контроллером, который создает экземпляр пользовательского интерфейса и говорит ему, как реагировать на события пользовательского интерфейса.

Я думаю, что это скорее представление о внедрении зависимостей в мир.Там могут быть важные преимущества.

Answer 4

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

Типичное использование для слушателей состоит в том, что они используются только в одномместо и для этой цели идеально подходят анонимные внутренние классы.Для интерфейсов с большим количеством методов (таких как MouseListeners) обычно существует соответствующий адаптер с пустыми реализациями всего, что затем может быть переопределено при необходимости.См. MouseAdapter.

Answer 5

Вы, безусловно, могли бы реализовать слушателя в отдельном файле класса в отдельном файле .java. Java 1.1 представила идею анонимного класса и внутреннего класса вместе с редизайном событий awt несколько лет назад. Причина в том, что много раз, слушатели, которых вы пишете, должны обновлять и / или читать поля из класса, который содержит объекты, где генерируются события. Обращаться к этим полям неудобно из не внутреннего / анонимного класса.

Как только вы будете больше использовать анонимные классы, вы увидите, что это облегчает написание и поддержку позже. Современные IDE в любом случае даже сгенерируют большую часть кода для вас. Например, введите эти две строки в IntelliJ IDEA и нажмите ctrl-shift-space. IntellJ вставит анонимный класс, который реализует все методы интерфейса, указанного в addActionListener ().

JButton jb = new JButton("ok");
jb.addActionListener(new 

Answer 6

Если вы видели их в примерах, возможно, вам будет проще. Большинство, вероятно, скажут вам просто взять текущий класс и реализовать слушатель. Какой из них выглядит проще: создание 2 классов в 2 файлах, использование вложенного слушателя внутри основного класса или просто использование основного класса в качестве слушателя? (Подсказка: это не первый)

Я ленивый, и у меня есть основной класс, реализующий интерфейс ActionListener. Это, конечно, работает только на очень простых графических интерфейсах. Для более крупных проектов вы должны разделить их.

Что касается содержания Слушателя в отдельном классе, спросите себя: нужно ли это использовать другим классам? Классы должны быть в их собственном файле, ТОЛЬКО если другим нужно их использовать. А совместное использование Слушателей - не самая лучшая идея, если у вас нет странного макета, в котором кнопки выполняют одно и то же, но в каждом классе их порядок различен.

Короче говоря: держите их вложенными или реализованными, а не отдельными, если это не необходимо. Однако необходимый случай будет немного и далеко между