Y a-t-il des avantages ou des inconvénients pour créer une classe imbriquée qui implémente ActionListener:
public class Foo implements ActionListener{
Foo(){
something.addActionListener(this);
}
//...
public void actionPerformed(ActionEvent e){
//...
}
}
4 Réponses :
Si la classe FOO n'a pas d'autre responsabilité que l'encapsulation de ce bouton, la première solution est en quelque sorte ok.
Cependant, dès que foo devient plus "quelque chose" que cela doit écouter alors cela devient désordonné. Je préfère la deuxième solution car elle est plus explicite et a une meilleure évolutivité.
Une solution encore meilleure peut être de créer une classe interne anomymé.
Je pense que la première approche est meilleure, car votre classe aura un code séparé pour la manipulation de l'action. Et généralement également, la composition est meilleure que l'héritage, une classe devrait donc étendre une classe ou implémenter une interface uniquement si elle est vraiment - un type super.
Aussi pour la maintenabilité, disons que FOO Class a une nouvelle exigence d'écouter un autre type d'événements différents, puis d'effectuer une action, dans ce cas, la première classe peut également être facilement modifiée.
Si je ne suis pas inquiet pour la maintenabilité, je préférerais aller pour une classe anonyme.
S'il vous plaît voir la réponse comme une réponse
Habituellement, vous voulez utiliser une classe imbriquée ou même anonyme plutôt que d'exposer ActionListener à l'API de la classe enfermante. (Classe publique FOO met en œuvre ActionListener -> Javadoc affirmera que FOO est un actelistener, même s'il s'agit généralement d'un détail de mise en œuvre -> Bad)
@Agnur, vous pouvez toujours utiliser des classes intérieures anonymes comme vos auditeurs et disposer d'une classe de contrôle autonome distincte et donc de code tout à fait maintenu, une technique que j'aime utiliser un peu. Par exemple:
Voir aussi Avantages aux classes imbriquées .