Quelles sont les différences entre le modèle de conception de la stratégie et le modèle de conception de l'État? Je parcourais pas mal d'articles sur le web mais je ne pouvais pas faire la différence clairement.

Quelqu'un peut-il expliquer la différence en termes simples?

Honnêtement, les deux modèles sont assez similaires dans la pratique, et la différence qui les définit a tendance à varier en fonction de la personne à qui vous demandez. Certains choix populaires sont:

• Les états stockent une référence à l'objet contextuel qui les contient. Les stratégies ne le font pas.
• Les états sont autorisés à se remplacer (IE: pour changer l'état de l'objet contextuel par autre chose), contrairement aux stratégies.
• Les stratégies sont transmises à l'objet contextuel en tant que paramètres, tandis que les états sont créés par l'objet contextuel lui-même.
• Les stratégies ne gèrent qu'une seule tâche spécifique, tandis que les États fournissent l'implémentation sous-jacente pour tout (ou presque tout) l'objet contextuel.

Une implémentation "classique" correspondrait à l'état ou à la stratégie pour chaque élément de la liste, mais vous utilisez des hybrides qui ont des mélanges des deux. Que ce soit en particulier un État-y ou une Stratégie-y est finalement une question subjective.

• Le modèle de stratégie consiste en réalité à avoir une implémentation différente qui accomplit (fondamentalement) la même chose, de sorte qu'une implémentation puisse remplacer l'autre comme la stratégie l'exige. Par exemple, vous pouvez avoir différents algorithmes de tri dans un modèle de stratégie. Les appelants à l'objet ne changent pas en fonction de la stratégie utilisée, mais quelle que soit la stratégie, l'objectif est le même (trier la collection).
• Le modèle d' État consiste à faire différentes choses en fonction de l'État, tout en laissant l'appelant soulagé du fardeau d'accommoder chaque État possible. Ainsi, par exemple, vous pourriez avoir une getStatus()méthode qui retournera différents statuts en fonction de l'état de l'objet, mais l'appelant de la méthode n'a pas besoin d'être codé différemment pour tenir compte de chaque état potentiel.

La différence réside simplement dans le fait qu'ils résolvent différents problèmes:

• Le modèle d' état traite de ce qu'est (état ou type) un objet (en) - il encapsule un comportement dépendant de l'état, tandis que
• le modèle de stratégie traite de la façon dont un objet exécute une certaine tâche - il encapsule un algorithme.

Les structures pour atteindre ces différents objectifs sont cependant très similaires; les deux modèles sont des exemples de composition avec délégation.

Quelques observations sur leurs avantages:

En utilisant l' État modèle de la classe de l' état de maintien (contexte) est soulagé de la connaissance de ce que l' état ou de type il est et ce qui indique ou types qui sont disponibles. Cela signifie que la classe adhère au principe de conception ouvert-fermé (OCP): la classe est fermée pour les changements dans les états / types, mais les états / types sont ouverts aux extensions.

En utilisant le modèle de stratégie , la classe utilisant un algorithme (contexte) est libérée de la connaissance de la façon d'effectuer une certaine tâche (- "l'algorithme"). Ce cas crée également une adhésion à l'OCP; la classe est fermée pour les changements concernant la façon d'effectuer cette tâche, mais la conception est très ouverte aux ajouts d'autres algorithmes pour résoudre cette tâche.
Cela améliore également probablement l'adhésion de la classe de contexte au principe de responsabilité unique (PRS). De plus, l'algorithme devient facilement disponible pour être réutilisé par d'autres classes.

Quelqu'un peut-il expliquer en termes simples?

Les modèles de conception ne sont pas vraiment des concepts "profanes", mais je vais essayer de le rendre aussi clair que possible. Tout modèle de conception peut être considéré en trois dimensions:

1. Le problème résolu par le modèle;
2. La structure statique du motif (diagramme de classes);
3. La dynamique du motif (diagrammes de séquence).

Comparons l'État et la stratégie.

Problème résolu par le modèle

L'État est utilisé dans l'un des deux cas [Livre du GoF p. 306] :

• Le comportement d'un objet dépend de son état et il doit changer son comportement au moment de l'exécution en fonction de cet état.
• Les opérations ont de grandes instructions conditionnelles en plusieurs parties qui dépendent de l'état de l'objet. Cet état est généralement représenté par une ou plusieurs constantes énumérées. Souvent, plusieurs opérations contiennent cette même structure conditionnelle. Le modèle State place chaque branche du conditionnel dans une classe distincte. Cela vous permet de traiter l'état de l'objet comme un objet à part entière qui peut varier indépendamment des autres objets.

Si vous voulez vous assurer que vous avez bien le problème résolu par le modèle d'état, vous devez pouvoir modéliser les états de l'objet à l'aide d'une machine à états finis . Vous pouvez trouver un exemple appliqué ici .

Chaque transition d'état est une méthode dans l'interface d'état. Cela implique que pour une conception, vous devez être assez certain des transitions d'état avant d'appliquer ce modèle. Sinon, si vous ajoutez ou supprimez des transitions, il faudra changer l'interface et toutes les classes qui l'implémentent.

Personnellement, je n'ai pas trouvé ce modèle utile. Vous pouvez toujours implémenter des machines à états finis à l'aide d'une table de recherche (ce n'est pas une méthode OO, mais cela fonctionne plutôt bien).

La stratégie est utilisée pour les [Livre du GoF p. 316] :

• de nombreuses classes apparentées ne diffèrent que par leur comportement. Les stratégies permettent de configurer une classe avec l'un des nombreux comportements.
• vous avez besoin de différentes variantes d'un algorithme. Par exemple, vous pouvez définir des algorithmes reflétant différents compromis espace / temps. Des stratégies peuvent être utilisées lorsque ces variantes sont implémentées en tant que hiérarchie de classes d'algorithmes [HO87].
• un algorithme utilise des données que les clients ne devraient pas connaître. Utilisez le modèle de stratégie pour éviter d'exposer des structures de données complexes et spécifiques à un algorithme.
• une classe définit de nombreux comportements, et ceux-ci apparaissent comme plusieurs instructions conditionnelles dans ses opérations. Au lieu de nombreuses conditions, déplacez les branches conditionnelles associées dans leur propre classe de stratégie.

Le dernier cas où appliquer la stratégie est lié à une refactorisation connue sous le nom de Remplacer conditionnel par le polymorphisme .

Résumé: l' État et la stratégie résolvent des problèmes très différents. Si votre problème ne peut pas être modélisé avec une machine à états finis, le modèle d'état probable n'est pas approprié. Si votre problème ne concerne pas l'encapsulation de variantes d'un algorithme complexe, alors la stratégie ne s'applique pas.

Structure statique du motif

State a la structure de classe UML suivante:

La stratégie a la structure de classe UML suivante:

Résumé: en termes de structure statique, ces deux motifs sont pour la plupart identiques. En fait, des outils de détection de modèles tels que celui-ci considèrent que " la structure des modèles [...] est identique, interdisant leur distinction par un processus automatique (par exemple, sans référence à des informations conceptuelles) " .

Il peut cependant y avoir une différence majeure si ConcreteStates décide lui-même des transitions d'état (voir les associations " pourrait déterminer " dans le diagramme ci-dessus). Il en résulte un couplage entre états concrets. Par exemple (voir la section suivante), l'état A détermine la transition vers l'état B. Si la classe Context décide de la transition vers l'état concret suivant, ces dépendances disparaissent.

Dynamique du motif

Comme mentionné dans la section Problème ci-dessus, l' état implique que le comportement change au moment de l'exécution en fonction de l' état d'un objet. Par conséquent, la notion de transition d' état s'applique, comme discuté avec la relation de la machine à états finis . [GoF] mentionne que les transitions peuvent être définies dans les sous-classes ConcreteState, ou dans un emplacement centralisé (tel qu'un emplacement basé sur une table).

Supposons une machine à états finis simple:

En supposant que les sous-classes décident de la transition d'état (en renvoyant l'objet d'état suivant), la dynamique ressemble à ceci:

Pour montrer la dynamique de la stratégie , il est utile d'emprunter un exemple réel .

Résumé : Chaque modèle utilise un appel polymorphe pour faire quelque chose en fonction du contexte. Dans le modèle State, l'appel polymorphe (transition) provoque souvent un changement dans l' état suivant . Dans le modèle de stratégie, l'appel polymorphe ne change généralement pas le contexte (par exemple, le paiement par carte de crédit une fois n'implique pas que vous paierez par PayPal la prochaine fois). Encore une fois, la dynamique du modèle d'état est déterminée par sa machine d'état de fininte correspondante , qui (pour moi) est essentielle pour corriger l'application de ce modèle.

Le modèle de stratégie implique de déplacer l'implémentation d'un algorithme d'une classe d'hébergement et de le placer dans une classe distincte. Cela signifie que la classe hôte n'a pas besoin de fournir l'implémentation de chaque algorithme lui-même, ce qui est susceptible de conduire à un code impur.

Les algorithmes de tri sont généralement utilisés comme exemple car ils font tous le même genre de chose (tri). Si chaque algorithme de tri différent est placé dans sa propre classe, le client peut facilement choisir l'algorithme à utiliser et le modèle fournit un moyen facile d'y accéder.

Le modèle d'état implique de modifier le comportement d'un objet lorsque l'état de l'objet change. Cela signifie que la classe hôte n'a pas fourni l'implémentation du comportement pour tous les différents états dans lesquels elle peut être. La classe hôte encapsule généralement une classe qui fournit les fonctionnalités requises dans un état donné, et bascule vers une classe différente quand l'état change.

Considérons un système IVR (Interactive Voice Response) qui gère les appels des clients. Vous voudrez peut-être le programmer pour gérer les clients sur:

• Jours ouvrés
• Vacances

Pour gérer cette situation, vous pouvez utiliser un modèle d'état .

• Vacances : IVR répond simplement en disant que «les appels ne peuvent être pris que les jours ouvrables entre 9h et 17h ».
• Jours ouvrables : il répond en connectant le client à un responsable du service client.

Ce processus de connexion d'un client à un responsable du support peut lui-même être mis en œuvre à l'aide d'un modèle de stratégie dans lequel les dirigeants sont sélectionnés en fonction de l'un des éléments suivants:

• Round Robin
• Moins récemment utilisé
• Autres algorithmes basés sur les priorités

Le modèle de stratégie décide du « comment » effectuer une action et le modèle d'état décide du « quand » les exécuter.

La stratégie représente des objets qui «font» quelque chose, avec les mêmes résultats de début et de fin, mais en interne en utilisant des méthodologies différentes. En ce sens, ils sont analogues à représenter la mise en œuvre d'un verbe. Le modèle d'état OTOH utilise des objets qui "sont" quelque chose - l'état d'une opération. Bien qu'ils puissent également représenter des opérations sur ces données, ils sont plus analogues à la représentation d'un nom qu'à un verbe et sont adaptés aux machines à états.

Stratégie: la stratégie est fixe et comprend généralement plusieurs étapes. (Le tri ne constitue qu'une étape et est donc un très mauvais exemple car il est trop primitif pour comprendre le but de ce modèle). Votre routine «principale» dans la stratégie appelle quelques méthodes abstraites. Par exemple, "Entrez la stratégie de la pièce", la "méthode principale" est goThroughDoor (), qui ressemble à: approachDoor (), if (verrouillé ()) openLock (); porte ouverte(); enterRoom (); tour(); ferme la porte(); if (wasLocked ()) lockDoor ();

Désormais, des sous-classes de cet "algorithme" général pour passer d'une pièce à une autre par une porte verrouillée possible peuvent mettre en œuvre les étapes de l'algorithme.

En d'autres termes, le sous-classement de la stratégie ne change pas les algorithmes de base, seulement les étapes individuelles.

QUE CI-DESSUS est un modèle de méthode de modèle. Maintenant, mettez les étapes appartenant ensemble (déverrouillage / verrouillage et ouverture / fermeture) dans leurs propres objets d'implémentation et déléguez-leur. Par exemple, une serrure avec une clé et une serrure avec une carte à code sont deux types de serrures. Déléguer de la stratégie aux objets "Step". Vous avez maintenant un modèle de stratégie.

Un modèle d'état est quelque chose de complètement différent.

Vous avez un objet enveloppant et l'objet enveloppé. L'enveloppé est "l'état". L'objet d'état est uniquement accessible via son wrapper. Vous pouvez maintenant changer l'objet encapsulé à tout moment, ainsi l'encapsuleur semble changer son état, ou même sa "classe" ou son type.

Par exemple, vous avez un service de connexion. Il accepte un nom d'utilisateur et un mot de passe. Il n'a qu'une seule méthode: l'ouverture de session (String userName, String passwdHash). Au lieu de décider par lui-même si une connexion est acceptée ou non, il délègue la décision à un objet d'état. Cet objet d'état vérifie généralement si la combinaison utilisateur / passe est valide et effectue une connexion. Mais maintenant, vous pouvez échanger le "Checker" par un qui ne permet aux utilisateurs privilégiés de se connecter (pendant le temps de maintenance par exemple) ou par un qui ne permet à personne de se connecter. Cela signifie que le "vérificateur" exprime le "statut de connexion" du système.

La différence la plus importante est: lorsque vous avez choisi une stratégie, vous vous en tenez à elle jusqu'à ce que vous en ayez fini. Cela signifie que vous appelez sa "méthode principale" et tant que celle-ci est en cours d'exécution, vous ne changez jamais de stratégie. OTOH dans une situation de modèle d'état pendant l'exécution de votre système, vous changez d'état arbitrairement comme bon vous semble.

Le modèle de stratégie est utilisé lorsque vous disposez de plusieurs algorithmes pour une tâche spécifique et que le client décide de l'implémentation réelle à utiliser lors de l'exécution.

Diagramme UML de l' article de modèle de stratégie wiki :

Principales caractéristiques:

1. C'est un modèle comportemental.
2. C'est basé sur la délégation.
3. Il change les tripes de l'objet en modifiant le comportement de la méthode.
4. Il est utilisé pour basculer entre les familles d'algorithmes.
5. Il modifie le comportement de l'objet au moment de l'exécution.

Référez-vous à cet article pour plus d'informations et des exemples du monde réel:

Exemple réel du modèle de stratégie

Le modèle d' état permet à un objet de modifier son comportement lorsque son état interne change

Diagramme UML de l'article du modèle d'état du wiki :

Si nous devons changer le comportement d'un objet en fonction de son état, nous pouvons avoir une variable d'état dans l'objet et utiliser le bloc de condition if-else pour effectuer différentes actions en fonction de l'état. Le modèle d' état est utilisé pour fournir un moyen systématique et à couplage perdant pour y parvenir grâce à des implémentations de contexte et d' état .

Reportez-vous à cet article de journaldev pour plus de détails.

Différences clés par rapport à la source et aux articles de journaldev :

1. La différence entre l' État et la stratégie réside dans le temps contraignant. La stratégie est un modèle unique, alors que l'État est plus dynamique .
2. La différence entre l' État et la stratégie réside dans l'intention. Avec Strategy, le choix de l'algorithme est assez stable . Avec State, un changement d'état de l'objet "context" le fait sélectionner dans sa "palette" d'objets Strategy .
3. Contexte contient l' état comme variable d'instance et il peut y avoir plusieurs tâches dont l' exécution peut dépendre de l' état alors que dans la stratégie modèle stratégie est passé comme argument à la méthode et le contexte objet n'a pas de variable pour le stocker.

Dans la langue du profane,

dans le modèle de stratégie, il n'y a pas d'états ou tous ont le même état. Tout ce que l'on a, c'est différentes façons d'accomplir une tâche, comme différents médecins traitent la même maladie d'un même patient avec le même état de différentes manières.

Dans le modèle d'état, subjectivement, il existe des états, comme l'état actuel du patient (par exemple, température élevée ou basse température), en fonction de la décision suivante (prescription de médicaments) et un état peut conduire à un autre état, donc il y a un état indiquer la dépendance (composition techniquement).

Si nous essayons techniquement de le comprendre, basé sur la comparaison de code des deux, nous pourrions perdre la subjectivité de la situation, car les deux se ressemblent beaucoup.

Les deux modèles délèguent à une classe de base qui a plusieurs dérivés, mais ce n'est que dans le modèle State que ces classes dérivées contiennent une référence à la classe de contexte.

Une autre façon de voir les choses est que le modèle de stratégie est une version plus simple du modèle d'État; un sous-motif, si vous le souhaitez. Cela dépend vraiment si vous voulez que les états dérivés conservent ou non les références au contexte (c'est-à-dire: voulez-vous qu'ils appellent des méthodes sur le contexte).

Pour plus d'informations: Robert C Martin (& Micah Martin) répondent à cela dans leur livre, "Agile Principles, Patterns and Practices in C #". ( http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 )

C'est une question assez ancienne, mais quand même, je cherchais aussi les mêmes réponses et c'est ce que j'ai découvert.

Pour le modèle d'état, considérons un exemple de bouton de lecture du lecteur médial. Lorsque nous jouons, il commence à jouer et rend le contexte conscient qu'il joue. Chaque fois que le client souhaite effectuer une opération de lecture, il vérifie l'état actuel du joueur. Maintenant, le client sait que l'état de l'objet est lu via l'objet contextuel, il appelle donc la méthode d'actions des objets d'état de pause. La partie du client réalisant l'état et sur quel état il doit agir peut être automatisée.

https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm

Dans le cas du modèle de stratégie, la disposition du diagramme de classes est identique à celle du modèle d'état. Le client vient à cet arrangement pour effectuer une opération. C'est qu'au lieu des différents états, il existe différents algorithmes, par exemple une analyse différente qui doit être effectuée sur le motif. Ici, les clients indiquent au contexte ce qu'ils veulent faire, quel algorithme (algorithme personnalisé défini par l'entreprise), puis il exécute cela.

https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm

Les deux implémentent le principe d'ouverture et de fermeture afin que le développeur puisse ajouter de nouveaux états au modèle d'état et au nouvel algorithme.

Mais la différence est ce qu'ils sont utilisés, c'est-à-dire un modèle d'état utilisé pour exécuter une logique différente en fonction d'un état de l'objet. Et dans un cas de stratégie de logique différente.

L'état vient avec un peu de dépendances au sein des classes dérivées de l'état: comme un état connaît les autres états qui le suivent. Par exemple, l'été vient après l'hiver pour n'importe quel état de saison, ou l'état de livraison après l'état de dépôt pour le shopping.

D'un autre côté, Strategy n'a pas de dépendances comme celles-ci. Ici, tout type d'état peut être initialisé en fonction du type de programme / produit.

La différence est discutée dans http://c2.com/cgi/wiki?StrategyPattern . J'ai utilisé le modèle de stratégie pour permettre de choisir différents algorithmes dans un cadre global d'analyse des données. Grâce à cela, vous pouvez ajouter des algorithmes sans avoir à modifier les cadres globaux et sa logique.

Un exemple typique est que vous disposez d'un cadre pour optimiser une fonction. Le cadre configure les données et les paramètres. Le modèle de stratégie vous permet de sélectionner des algorithmes tels que les descentes sttepest, les gradients conjugués, les BFGS, etc. sans modifier le cadre.

La stratégie et le modèle d'État ont la même structure. Si vous regardez le diagramme de classe UML pour les deux modèles, ils se ressemblent exactement, mais leur intention est totalement différente. Le modèle de conception d'état est utilisé pour définir et gérer l'état d'un objet, tandis que le modèle de stratégie est utilisé pour définir un ensemble d'algorithmes interchangeables et permet au client de choisir l'un d'entre eux. Le modèle de stratégie est donc un modèle axé sur le client, tandis que Object peut gérer lui-même l'état.

En bref, avec le modèle de stratégie, nous pouvons définir un comportement à la volée, avec le modèle d'état, nous pouvons être sûrs, qu'un objet changera son comportement en interne avec le changement de son état.

Lorsque vous avez un projet qui peut être divisé en 2 tâches:

tâche 1: vous pouvez utiliser l'un des deux algorithmes différents pour accomplir: alg1, alg2

tâche 2: vous pouvez utiliser l'un des trois algorithmes différents pour accomplir: alg3, alg4, alg5

alg1 et alg2 sont interchangeables; alg3, alg4 et alg5 sont interchangeables.

Le choix de l'algorithme à exécuter dans les tâches 1 et 2 dépend des états:

état 1: vous avez besoin d'alg1 dans la tâche 1 et d'alg3 dans la tâche 2

état 2: vous avez besoin d'alg2 dans la tâche 1 et d'alg5 dans la tâche 2

Votre contexte peut changer d'objet d'état de l'état 1 à l'état 2. Ensuite, votre tâche serait accomplie par alg2 et alg5, au lieu de alg1 et alg3.

Vous pouvez ajouter des algorithmes plus interchangeables pour la tâche 1 ou la tâche 2. Il s'agit d'un modèle de stratégie.

Vous pouvez avoir plusieurs états avec différentes combinaisons d'algorithmes dans la tâche 1 et la tâche 2. Le modèle d'état vous permet de passer d'un état à un autre et d'effectuer différentes combinaisons d'algorithmes.

La «stratégie» n'est qu'un algorithme que vous pouvez modifier dans différentes circonstances selon vos besoins, et il traite quelque chose pour vous. Ex. vous pouvez choisir comment compresser un fichier. zip ou rar ... dans une méthode.

Mais 'State' PEUT changer tout le comportement de votre objet, quand il change, Même il peut changer d'autres champs ... c'est pourquoi il a une référence à son propriétaire. Vous devez noter que la modification d'un champ d'objet peut modifier le comportement de l'objet. Ex. lorsque vous changez State0 en State1 dans obj, vous changez un entier en 10 .. donc quand nous appelons obj.f0 () qui fait un calcul et utilise cet entier, cela affecte le résultat.