Le modèle de stratégie devrait-il être apatride?

Non, pourquoi devrait-il être apatride? La stratégie pourrait être n'importe quoi, il représente simplement une unité de fonctionnalité enfichable de l'exécution qui vous permet d'étendre le comportement de la classe de consommation. Autant que je sache, il n'y a rien que cela suggère l'exigence d'apatridie, ni à l'immutabilité.

L'intention du modèle de stratégie est de travailler sur les arguments de la méthode de la stratégie directement dans la méthode de la portée locale. La classe de stratégie elle-même peut bien sûr contenir certains champs à tout moment, mais les arguments de la méthode ne doivent en aucun cas être attribués à ces champs, car il peut introduire des problèmes de threadsafety si l'objet de stratégie est utilisé plus d'une fois.

Oui, comme il s'agit de choix d'algorithmes surtout. L'algorithme de béton peut avoir un état, mais pas le sélecteur.

Au fait dans cette stratégie, nous n'avons pas une classe. Quelle classe concrete voulez-vous dire? Dans quel rôle?

L'apatridie fait référence au fait qu'aucune donnée n'est préservée entre les points d'une stratégie; c'est-à-dire si vous exécutez la même stratégie deux fois, rien de la crise précédente de la stratégie ne se poursuivrait. Cela est bénéfique en ce sens que cela vous permet d'économiser de "réinitialiser" vos implémentations de stratégie si nécessaire.

Notez que dans la description de la mise en œuvre du modèle de stratégie, ils font référence à un contexte (@ page 317 dans mon livre) contenant les données dont la stratégie doit exécuter. Tous les «Etat» requis par les implémentations devraient probablement aller dans ces objets de contexte.

Cela signifie que les implémentations de stratégie elles-mêmes sont apatrides, mais le modèle dans son ensemble a l'état que les données requises sont transmises dans un contexte.

Par exemple, si vous aviez des implémentations de stratégie pour les opérations mathématiques, il y a au moins 2 façons de le faire. Le premier serait de définir Arg1 et Arg2 (et 3 et 4 ...) sur les implémentations de la stratégie lorsque vous les construisez. Ensuite, lorsque vous exécutez la mise en œuvre, saisiriez ses champs et feriez l'opération. Le problème est que si vous exécutez à nouveau la même implémentation, vous devez réinitialiser tous ses champs (ou créer une nouvelle implémentation).

La deuxième façon serait de créer un contexte contenant tous les arguments. Les implémentations de l'état des États saisiraient les valeurs qu'il a besoin du contexte. Ensuite, vous pouvez réutiliser chaque instance de votre mise en œuvre de la stratégie, simplement en passant un nouveau contexte à chaque fois. Pas de souci de recréer de nouvelles instances des implémentations ou d'oublier de réinitialiser l'instance de mise en œuvre. Bien sûr, vous devez toujours gérer correctement les contextes.

Une classe de stratégie encapsule une action, pas une chose. Donc, bien que vous puissiez si vous aviez vraiment dû, cela n'aurait pas de sens de garder l'état dedans. Pensez-y comme un verbe, pas un nom. Ou au moins comme un nom qui décrit une action. D'autre part, vous pouvez toujours paramétrer la stratégie et transmettre l'état de l'objet client par l'appel de méthode ou similaire.

Aussi, si une classe est apatride ou étatique ne dépend pas vraiment du mot-clé final sur ses champs. Exemples:

• Lorsqu'il est utilisé sur des objets final seulement signifie que la référence à un objet peut ne pas être modifiée. Vous pouvez toujours changer le contenu de cet objet, comme ses champs. Dans ce cas, votre classe est stipulable bien que son domaine soit définitif.
• Si le champ est vraiment une constante, alors à terme pour la plupart des fins et des objectifs que vous pouvez le considérer. Par exemple, vous pouvez déclarer un champ final statique privé , puis assurez-vous de ne jamais rien faire pour changer l'état de l'objet référencé.

  Edit: Essayons de distinguer des paramètres de stratégie elle-même et des paramètres d'une exécution particulière de cette stratégie. Si la classe de stratégie est apatride, il n'est pas question d'avoir plus d'une instance de cette classe, ce qui rend l'objet, pas la classe, représente l'action elle-même et une méthode exécution représente une exécution particulière de cette stratégie.

  Maintenant, si nous avons un paramètre de la stratégie elle-même, il est de sens que le paramètre a la même valeur pour toutes les exécutions de cette stratégie. Ainsi, il peut être placé dans une méthode constante et constante qui renvoie une constante (si nous ne faisons pas de choses statiques) ou même du code gras. Comme expliqué ci-dessus, cela peut être mis en œuvre de manière apatride.

  D'autre part, si le paramètre décrit une exécution particulière de la stratégie, puis transmettez-la comme paramètre à la méthode. Ça fera.

  Remarque supplémentaire: il y a une bonne raison d'utiliser des objets d'action avec des «adverbes» emballées dans son état si nous voulons, par exemple, avoir une sorte de file d'exécution d'action avec retard, planification ... il y a un modèle pour cela aussi - commande.