Реализация подкласса JFrame и интерфейса ActionListener

Question

Почему extends JFrame implements ActionListener плохое дизайнерское решение?

Answer 1

Пара баллов:

• Расширение JFrame, вероятно, неправильный подход
• Реализация ActionListener на JFrame, вероятно, приведет к не-ООП-коду.

Неправильный подход?

Если идея заключается в том, что создается приложение с графическим интерфейсом, то не делается расширение JFrame., но на самом деле написание приложения.

Следовательно, JFrame будет частью приложения, а не самого приложения.Следовательно, JFrame должен быть объектом в классе.

Реализация ActionListener на JFrame, вероятно, приведет к не-ООП-коду

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

Если бы сам JFrame былчтобы получить события, то как бы выглядел actionPerformed метод?

Возможно что-то вроде этого:

public void actionPerformed(ActionEvent e) {
  Object source = e.getSource();

  // Find out which component fired the event
  if (source == masterButton) {
    // ... do something
  } else if (source == anotherButton) {
    // ... do something else
  } else if (...)
    // ... and so on ...
  } else if (...)
    // ... and so on ...
  }
}

Yikes.

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

---

Если, например, приложение с графическим интерфейсом имеет экземпляры ActionLister s, которые ответилидля каждого компонента мы сможем разбить действия и связь метода actionPerformed со всеми компонентами в графическом интерфейсе.

Например:

JButton masterButton = new JButton();
masterButton.addActionListener(new MasterButtonActionListener());

JButton anotherButton = new JButton();
anotherButton.addActionListener(new AnotherButtonActionListener());

Таким образом, будет ActionListeners для каждой кнопки, которая предположительно имеетдругая функциональность.MasterButtonActionListener несет ответственность за обработку событий от masterButton - ему не нужно знать о других кнопках в приложении.

Кроме того, это будет способствовать повторному использованию компонентов в другихприложения или другие части приложения без необходимости копировать и вставлять части монолитного оператора if-else в методе actionPerformed.

Answer 2

Если вы читаете Эффективную Java, пункт 16 гласит:

" Пользу композиции над наследованием "

. Прочитайте объяснение, данное здесь

Answer 3

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

Пример:

class ExitAction extends AbstractAction{    
    public ExitAction(){
        super("Exit");
    }
    @Override
    public void actionPerformed(ActionEvent e) {
        System.out.println("Exiting");
    }
}

JButton exitButton = new JButton(new ExitAction());

Взгляните на Как использовать действия в руководстве по Java:

Answer 4

Кроме того, A JFrame обычно не получает действий. Его дочерние объекты будут благодетелями ActionEvent.

Answer 5

Я считаю, что это плохой дизайн .. Потому что вы смешиваете код контроллера с представлением .. если вы хотите следовать шаблону mvc, вам не следует смешивать их ..