Преимущества вложенных классов для слушателей в графических интерфейсах - PullRequest
Новая
       17

Преимущества вложенных классов для слушателей в графических интерфейсах

11 голосов
/ 23 февраля 2011

Для проектов приличного размера мне сказали, что, когда у вас есть классы, расширяющие JPanels, лучше всего использовать вложенные классы для реализации слушателей.Например, у меня может быть класс FactoryScreen, расширяющий JPanel, и вложенный класс FactoryScreenBrain, который реализует все необходимые прослушиватели.

Мне никогда не удавалось получить хорошее объяснение конкретных преимуществ или недостатков инкапсуляции моих классов таким образом, и до сих пор всегда были классы, которые расширяют JPanel и реализуют слушатели.Может ли кто-нибудь дать мне руководство по этому вопросу?

Ответы [ 3 ]

8 голосов
/ 23 февраля 2011

Наличие внутренних классов для ваших слушателей делает цель всех этих слушателей очень ясной. Также иногда можно избежать многих проверок if за счет немного большего кодирования.

Если у вас есть панель 

public class MyPanel extends JPanel implements ActionListener
...
    button1.addActionListener(this);
    button2.addActionListener(this);
    checkbox1.addActionListener(this);
    timer3.addActionListener(this);

    public void actionPerformed(ActionEvent e)
    {
        if(e.getSource() == button1)
        else...
        ... //potentially many elses
    }

очень трудно точно увидеть, что происходит в вашем actionPerformed, потому что он обрабатывает так много разных событий одновременно. Имея панель: 

public class MyPanel extends JPanel
...
    button1.addActionListener(new ButtonListener());
    button2.addActionListener(new ButtonListener());
    checkbox1.addActionListener(new CheckBoxListener());
    timer3.addActionListener(new TimerListener());

    private class TimerListener implements ActionListener
    {
        public void actionPerformed(ActionEvent e)
        {
            //do stuff related only to timers
        }
    }

Теперь, если у вашего таймера есть проблема, вы можете легко определить класс с проблемой.

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

6 голосов
/ 23 февраля 2011

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

Кстати, хороший вопрос.

2 голосов
/ 23 февраля 2011

Если вы расширяете компонент и внедряете одного или нескольких слушателей, заманчиво добавить слушателей в конструктор. Это потенциально обнажает ссылку на не полностью построенный объект - иногда называемый , избежавший этого . Работа исключительно на EDT снижает риск; но анонимный внутренний класс может еще больше уменьшить его. Проблемы с отражением или косвенным воздействием остаются.

...