Champ protégé contre méthode protégée vs implémentation de l'interface pour les gestionnaires d'actions

Question

J'ai une classe qui représente une page de base avec les boutons "retourner", "aller de l'avant" et "canel" dans Wicket. Mais toutes les pages n'ont pas tous les boutons, e. g. la première page n'a pas "revenir" évidemment.

Mon idée est de définir un actionHandler générique

public interface ActionHandler { 
    void perform(); 
} 

et laisser les sous-classes retournent actions qu'ils soutiennent:

public Derived extends BasicPage { 
    protected ActionHandler getForwardHandler() { 
    return new ActionHandler() { 
     void perform() { 
     doIt(); 
     } 
    }; 
    } 
} 

La question est: pourquoi ne pas utiliser des champs protégés?

public Derived extends BasicPage { 
    protected forwardHandler = new ActionHandler() { 
     void perform() { 
     doIt(); 
     } 
    }; 
} 

Une autre option serait de ne pas utiliser l'héritage (qui n'a pas de sens vraiment ici) et définir les ActionHandlers de l'extérieur:

Toolbar toolbar = new Toolbar(); 
toolbar.setForwardHandler(new ActionHandler() { 
    void perform() { 
    doIt(); 
    } 
}); 

La raison pour laquelle je ne suis pas en utilisant des interfaces comme ForwardHandler, et CancelHandler est, que je veux passer le gestionnaire à une barre d'outils, ce qui prend ActionHandlers comme paramètres. Ou passeriez-vous la page entière à la barre d'outils et laissez la barre d'outils décider quels boutons afficher en fonction des interfaces implémentées? On dirait une mauvaise OOP pour moi.

L'idée est que chaque page doit définir une nouvelle barre d'outils, mais il serait peut-être plus simple ...

Answer 1

Pourquoi ne pas utiliser un champ de protection? Cela fonctionnerait; sous-classes serait simplement réaffecter le champ à la ActionHandler qu'ils désirent.

Cependant, je pense que c'est pire qu'une méthode protégée. Vous tentez de définir un comportement et le comportement est défini par des méthodes. Avec un champ, vous affectez sa valeur initiale à null ou à un gestionnaire factice, ce qui laisse l'objet dans un état étrange, où le comportement qui devrait être intrinsèquement défini par l'objet peut être accidentellement laissé indéfini.

Puisqu'une méthode protégée n'est vraiment pas plus complexe ou plus de code, je pense que c'est approprié. Il peut avoir une implémentation par défaut qui ne fait rien.

Je ne sais pas s'il est logique que les sous-classes concrètes aient leur comportement défini par un appelant. Si FooPage représente vraiment la page Foo, et Foo a un comportement fixe, alors FooPage devrait le définir. Je ne sais pas s'il y a de mauvais effets secondaires, mais passer quelque chose comme l'entité page à un objet pour le laisser décider de son comportement ne semble pas terrible en principe.