Компонент Swing, слушающий себя против внутренних классов - PullRequest
1 голос
/ 02 мая 2011

Я только что получил плохую обратную связь по проекту uni и мне нужно непредвзятое разъяснение;

Может кто-нибудь объяснить, когда я должен использовать (анонимные) классы внутреннего слушателя по сравнению с компонентами, которые слушают сами себя?(a против b)

a)

public class myButton extends JButton {

    public myButton() {

        addActionListener(new ActionListener() {

            public void actionPerformed(ActionEvent e) {
                // handling code...

            }
        });
    }
}

b)

public class myButton extends JButton implements ActionListener {

    public myButton() {

        addActionListener(this);
    }

    public void actionPerformed(ActionEvent e) {

        // handle the event
    }
}

Спасибо, ребята, Митч

Ответы [ 4 ]

4 голосов
/ 02 мая 2011

с)

JButton myButton = new JButton(); 
myButton.addActionListener(new ActionListener() { 
    public void actionPerformed(ActionEvent e) { 
        // handling code...
    }
}); 
3 голосов
/ 02 мая 2011

Для случаев, когда у вас есть несколько кнопок с различным поведением, более удобно назначить отдельный анонимный класс для каждой кнопки, вы все равно можете реализовать ActionListener в своем классе и обрабатывать событие в соответствии с источником:

void actionPerformed(ActionEvent e) { 
    if (e.getSrouce() == button1)
    { ... }
    else if (e.getSource() == button2)
    { ... }
    // ...
} 
1 голос
/ 02 мая 2011

Дело в том, что когда вы объявляете свой класс myButton для реализации ActionListener, вы увеличиваете его видимый API (т.е. добавляете новый публичный метод actionPerformed(), который можно свободно вызывать любым кодом, который содержит ссылку на * 1004). *).

Поскольку вы, вероятно, не хотите, чтобы "actionPerformed" являлся частью myButton API, вам следует использовать внутренний класс, который сохранит общедоступный API myButton.

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

1 голос
/ 02 мая 2011

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

В частности, они являются единственным способом использования классов Adapter (пустых классов, которые уже реализуют некоторые конкретные интерфейсы Listener, поэтому вам нужно только перезаписать нужные вам методы, и вам не нужно предоставлять пустую реализацию тех, которые тебе не нужно).

...