Je suis en train de mettre en œuvre quelques stratégies (modèle de stratégie) qui ont un comportement commun et Je suis indécis là où les opérations communes devraient vivre.
Toutes les recommandations ou préférences?
Note Le niveau que je travaille est le niveau de stratégie, pas le niveau de contexte (voir Wikipedia Link).
4 Réponses :
Il existe de nombreuses façons d'y parvenir.
Utilisez une classe abstraite et apportez les parties variables de l'exécution en méthodes abstraites => Certaines stratégies implémentaient toutes les opérations (en remplaçant les méthodes abstraites), tandis que d'autres pourraient ignorer les options facultatives. Notez que dans ce cas, les opérations facultatives pourraient être des méthodes de crochet vides plutôt que des méthodes abstraites. De cette façon, vous évitez les tracas de devoir mettre en œuvre ces opérations comme méthodes vides dans la sous-classe.
Utilisez une interface "stratégie" réelle (avec une méthode d'exécution comme dans l'article Wikipedia que vous avez indiqué). La classe client serait alors fournie par une mise en œuvre de la stratégie (pourrait être une classe intérieure anonyme ou une classe de stratégie pleine remplie réelle).
Le premier est plus simple mais plus rigide: si vous devez modifier le nombre d'opérations (spécialement abstrait), toutes les sous-classes doivent être mises à jour.
La seconde est plus flexible, mais vous devrez trouver un moyen de "partager" des opérations communes entre différentes stratégies, en déléguant ou en utilisant des méthodes utilitaires statiques.
"La seconde est plus flexible, mais vous devrez trouver un moyen de" partager "des opérations communes entre différentes stratégies, que ce soit en déléguant ou en utilisant des méthodes utilitaires statiques." - La stratégie est le niveau que je travaille à et les «parties communes» comme vous dites est le problème que j'essaie de résoudre.
Les parties communes sont-elles bien adaptées aux petites unités d'activité? Ce que je veux dire par là est: pourraient-ils être modélisés comme des fonctions? Si tel est le cas, je suggère d'encapsuler ces opérations dans de petites classes «opération» et de réutiliser ces stratégies d'accrovage. Les avantages sont la testabilité et la réutilisabilité dans ce cas.
Petites unités Oui, mais pas à travers l'entreprise. Applicable uniquement pour les stratégies - Donc, je pense que le paquet utile statique restreint, pensées?
Si tout ce dont vous avez besoin est une logique apatride, les méthodes statiques restreintes sont aussi bonnes que des objets. Vous perdez le polymorphisme (et l'amour et le soutien des puristes de OO ;-) Mais c'est toujours aussi testable et réutilisable.
Il y a une autre option en plus des deux que vous avez énumérées:
Cela me semble que vous aimeriez vous une sorte de composition où vous ne pouvez tirer que dans les fonctionnalités que vous avez besoin. Peut-être que vous pouvez emballer vos opérations à l'aide du modèle de commande, puis assembler vos stratégies à partir de ceux-ci?
Avantages:
Les stratégies sont très similaires aux commandes dans ce cas, donc je ne vois pas comment je pourrais éviter l'héritage, car les commandes auront toujours besoin de partager des fonctions communes à travers eux si je vous comprends correctement, comment vous proposez-vous que la mise en œuvre?
Je suggère que les stratégies sont composées de commandes. Chaque «fonction» est une instance de commande. Vous pouvez ensuite simplement composer vos stratégies en choisissant et en choisissant des commandes appropriées.
Il y a une raison ... une raison Vous pouvez donc ajouter plus de méthodes à une date ultérieure.
Avec une classe abstraite ou une interface, toute modification que vous apportez à cette classe / interface doit être modifiée dans toutes les classes qui héritent d'elle. Ceci est particulièrement problématique si vous écrivez une API publique.
Le cadre Java contient des classes utiles avec des méthodes statiques dispersées partout. Les plus connus sont dans le java.util package: collections et Tableaux .
Bon point. Personnellement, je pense que statique est la voie à suivre. Les fonctions conviennent bien au motif de la viewHelper ainsi sur la complication de cela semble inutile.
Sur ce sujet, je pense que la bibliothèque restée et XMLSlurper (dans le projet Groovy) sont tous deux excellents exemples d'utilisation de classes utilitaires statiques.
@PowerLord je suis curieux que vous stipiez à cette réponse aujourd'hui?
S'il est déclaré comme
Je préfère aller avec l'abstraction lorsqu'il est nécessaire de suivre le modèle Open-Fermer I.E, le programme sera ouvert à l'extension mais fermé pour la modification ...