Sempre pensei que fosse fato consumado ver implementações de javax.swing.Action como Command’s (GoF), então não me preocupei em embasar muito essa visão. Pode ser que não seja bem assim. De qualquer forma, eu voltei às minhas fontes porque acho que vai ser útil colocar alguma coisa aqui que vá além do “eu acho”.
Do livro The Design Patterns - Java Companion, de James W. Cooper - ótima introdução aos GoF patterns em Swing - capítulo The Command Pattern, pág, 142:
[quote]If you give
every control its own actionListener class, you are in effect creating
individual command objects for each of them. And, in fact, this is really what
the designers of the Java 1.1 event model had in mind. [. . .]
To implement this approach, we create little classes each of which
implements the ActionListener interface:
[code]
class btnRed implements ActionListener {
public void actionPerformed(ActionEvent e) {
p.setBackground(Color.red);
}
}
class fileExit implements ActionListener {
public void actionPerformed(ActionEvent e) {
System.exit(0);
}
}[/code]
and register them as listeners in the usual way.
mnuOpen.addActionListener(new fileOpen());
mnuExit.addActionListener(new fileExit());
btnRed.addActionListener(new btnRed());
[/quote]
Nesse exemplo, o autor implementa ActionListener diretamente, ao invés de Action ou AbstractAction.
Mais. Em Using the Swing Action Architecture, na conclusão, está escrito:
Um dos motivos que põe em dúvida a eficácia da utilização de Action’s como controller, é o efeito colateral dos Command’s (ainda, do livro The Design Patterns - Java Companion):
[quote]
The main disadvantage of the Command pattern is a proliferation of
little classes that either clutters up the main class if they are inner or clutters
up the program namespace if they are outer classes.[/quote]