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

• Les États stockent une référence à l’object de contexte qui les contient. Les stratégies ne le font pas.
• Les États sont autorisés à se remplacer (IE: changer l’état de l’object contextuel en autre chose), alors que les stratégies ne le sont pas.
• Les stratégies sont transmises à l’object contextuel en tant que parameters, tandis que les états sont créés par l’object 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’object contextuel.

Une implémentation “classique” correspondrait à l’état ou à la stratégie pour chaque élément de la liste, mais vous rencontrez des hybrides qui ont des mélanges des deux. La question de savoir si un État particulier est plus un État ou une stratégie est finalement une question subjective.

Le modèle de stratégie consiste en réalité à avoir une implémentation différente qui accomplit (essentiellement) la même chose, de sorte qu’une implémentation puisse remplacer l’autre comme le requirejs la stratégie. Par exemple, vous pouvez avoir différents algorithmes de sorting dans un modèle de stratégie. Les appelants à l’object ne changent pas en fonction de la stratégie utilisée, mais quelle que soit la stratégie, l’objective est le même (sortinger la collection).

Le modèle de l’État consiste à faire différentes choses en fonction de l’état, tout en laissant à l’appelant le soin de s’adapter à tous les états possibles. Ainsi, par exemple, vous pouvez avoir une méthode getStatus() qui renverra des statuts différents en fonction de l’état de l’object, mais l’appelant de la méthode n’a pas besoin d’être codé différemment pour prendre en compte 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 que (état ou type) un object est (en) – il encapsule un comportement dépendant de l’état, alors que
• Le modèle de stratégie traite de la manière dont un object exécute une certaine tâche – il encapsule un algorithme.

Les concepts pour atteindre ces différents objectives 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 le modèle d’état, la classe (context) contenant l’état est déchargée de la connaissance de l’état ou du type et des états ou types disponibles. Cela signifie que la classe adhère au principe de conception à fermeture ouverte (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 (contextuelle) utilisant l’algorithme est dispensée de savoir comment exécuter une tâche donnée (- “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’exécuter cette tâche, mais la conception est très ouverte aux ajouts d’autres algorithmes pour résoudre cette tâche.
Cela améliore probablement aussi l’adhésion de la classe de contexte au principe de responsabilité unique (SRP). En outre, l’algorithme devient facilement disponible pour être réutilisé par d’autres classes.

Quelqu’un peut-il s’il vous plaît expliquer en termes simples?

Les modèles de conception ne sont pas vraiment des concepts «profanes», mais je vais essayer de le rendre le plus clair 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 classe);
3. La dynamic du motif (diagrammes de séquence).

Comparons l’état et la stratégie.

Le problème résout le problème

L’état est utilisé dans l’un des deux cas [livre GoF p. 306] :

• Le comportement d’un object dépend de son état et il doit modifier 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’object. Cet état est généralement représenté par une ou plusieurs constantes énumérées. Souvent, plusieurs opérations contiendront cette même structure conditionnelle. Le modèle d’état place chaque twig du conditionnel dans une classe distincte. Cela vous permet de traiter l’état de l’object comme un object à part entière pouvant varier indépendamment des autres objects.

Si vous voulez vous assurer que le problème est résolu, vous devriez pouvoir modéliser les états de l’object à 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 sûr des transitions d’état avant d’appliquer ce modèle. Sinon, si vous ajoutez ou supprimez des transitions, vous devrez modifier 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 en utilisant une table de consultation (ce n’est pas un moyen OO, mais cela fonctionne plutôt bien).

La stratégie est utilisée pour les éléments suivants [livre 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 spatio-temporels. Les stratégies peuvent être utilisées lorsque ces variantes sont implémentées sous la forme d’une hiérarchie de classes d’algorithmes [HO87].
• un algorithme utilise des données que les clients ne doivent pas connaître. Utilisez le modèle de stratégie pour éviter d’exposer des structures de données complexes et spécifiques aux algorithmes.
• une classe définit de nombreux comportements, et ceux-ci apparaissent sous la forme de plusieurs instructions conditionnelles dans ses opérations. Au lieu de nombreuses conditions, déplacez les twigs conditionnelles associées dans leur propre classe de stratégie.

Le dernier cas d’application de la stratégie est lié à un refactoring appelé Remplacer conditionnellement avec polymorphism .

Résumé: Etat et 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, la stratégie ne s’applique pas.

Structure statique du motif

L’état 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 modèles sont pour la plupart identiques. En fait, les outils de détection de modèle 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 les ConcreteStates décident eux-mêmes des transitions d’état (voir les associations ” pourraient déterminer ” dans le diagramme ci-dessus). Cela se traduit par un couplage entre des é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 le prochain état concret, ces dépendances disparaissent.

Dynamique du motif

Comme mentionné dans la section Problème ci-dessus, State implique que le comportement change à l’exécution en fonction de l’ état d’un object. 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’object d’état suivant), la dynamic ressemble à ceci:

Pour montrer la dynamic 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 d’état, l’appel polymorphe (transition) provoque souvent une modification de 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 dynamic du modèle d’état est déterminée par sa machine d’état correspondante , qui (pour moi) est essentielle pour corriger l’application de ce modèle.

Le modèle de stratégie consiste à déplacer l’implémentation d’un algorithme à partir d’une classe d’hébergement et à 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 incorrect.

Les algorithmes de sorting sont généralement utilisés comme exemple car ils font tous le même genre de choses (sorting). Si chaque algorithme de sorting 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 la modification du comportement d’un object lorsque l’état de l’object change. Cela signifie que la classe hôte ne fournit pas 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 requirejses dans un état donné et passe à une classe différente. quand l’état change.

La stratégie représente des objects qui “font” quelque chose, avec les mêmes résultats de début et de fin, mais en interne en utilisant différentes méthodologies. En ce sens, ils sont analogues à la représentation de la mise en œuvre d’un verbe. Le modèle d’état OTOH utilise des objects 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 que d’un verbe et sont adaptés aux machines à états.

Stratégie: la stratégie est fixe et comprend généralement plusieurs étapes. (Le sorting ne constitue qu’une étape et constitue 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 “Enter Room Strategy”, “main-method” est goThroughDoor (), qui ressemble à: approachDoor (), if (locked ()) openLock (); porte ouverte(); enterRoom (); tour(); ferme la porte(); if (wasLocked ()) lockDoor ();

Désormais, les sous-classes de cet “algorithme” général permettant de passer d’une pièce à une autre par une porte verrouillée possible peuvent implémenter les étapes de l’algorithme.

En d’autres termes, sous-classer la stratégie ne modifie pas les algorithmes de base, mais uniquement les étapes individuelles.

QUE CI-DESSUS est un modèle de méthode de modèle. Maintenant, placez les étapes (délocking / locking et ouverture / fermeture) dans leurs propres objects d’implémentation et déléguez-les. Par exemple, une serrure avec une clé et une serrure avec une carte de code sont deux types de serrures. Déléguer de la stratégie aux objects “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 object enveloppant et l’object encapsulé. Le enveloppé est “l’état”. L’object state est uniquement accessible via son wrapper. Maintenant, vous pouvez changer l’object emballé à tout moment, ainsi le wrapper 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 ne possède qu’une seule méthode: logon (Ssortingng userName, Ssortingng passwdHash). Au lieu de décider pour lui-même si une connexion est acceptée ou non, il délègue la décision à un object d’état. Cet object d’état vérifie généralement simplement si la combinaison utilisateur / passe est valide et effectue une connexion. Mais maintenant, vous pouvez échanger le “Checker” par un autre qui permet uniquement aux utilisateurs privilégiés de se connecter (pendant un temps de maintenance, par exemple) ou par un utilisateur qui ne se connecte pas. Cela signifie que le “vérificateur” exprime le “statut de connexion” du système.

La différence la plus importante est la suivante: lorsque vous avez choisi une stratégie, vous la respectez jusqu’à ce que vous en ayez fini. Cela signifie que vous appelez sa “méthode principale” et que tant que celui-ci fonctionne, vous ne changez jamais de stratégie. Dans une situation de modèle d’état pendant l’exécution de votre système, vous changez d’état de manière arbitraire comme bon vous semble.

Envisagez un système RVI (réponse vocale interactive) traitant les appels des clients. Vous voudrez peut-être le programmer pour gérer les clients sur:

• Journées de travail
• 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 de travail : il répond en connectant le client à un responsable du service client.

Ce processus de connexion d’un client à un responsable du support peut être implémenté à l’aide d’un modèle de stratégie dans lequel les frameworks sont choisis en fonction de l’un des éléments suivants:

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

Le modèle de stratégie décide de la manière dont une action doit être effectuée et le modèle d’état décide du moment où il doit les exécuter.

Le modèle de stratégie est utilisé lorsque vous avez 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 du wiki Article du modèle de stratégie:

Principales caractéristiques:

1. C’est un modèle de comportement.
2. C’est basé sur la délégation.
3. Il modifie les entrailles de l’object en modifiant le comportement de la méthode.
4. Il permet de passer d’une famille d’algorithmes à l’autre.
5. Il modifie le comportement de l’object au moment de l’exécution.

Référez-vous à ce post pour plus d’informations et des exemples concrets:

Real World Exemple de modèle de stratégie

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

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

Si nous devons modifier le comportement d’un object en fonction de son état, nous pouvons avoir une variable d’état dans l’object 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 sans couplage pour y parvenir grâce à la mise en œuvre du contexte et de l’ état .

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

Principales différences entre les articles de presse et les articles de journaux:

1. La différence entre État et stratégie réside dans le temps contraignant. La stratégie est un modèle unique, alors que l’état est plus dynamic .
2. La différence entre l’ Etat et la stratégie réside dans l’intention. Avec Strategy, le choix de l’algorithme est assez stable . Avec State, une modification de l’état de l’object “context” entraîne sa sélection dans sa “palette” d’objects Stratégie .
3. Le contexte contient l’état comme variable d’instance et il peut exister plusieurs tâches dont l’implémentation peut dépendre de l’ état, alors que dans la stratégie , la stratégie est passée en argument à la méthode et l’object contextuel n’a aucune variable pour le stocker.

En langage profane,

Dans le schéma de stratégie, il n’y a pas d’états ou tous ont le même état. Il n’y a que différentes manières d’exécuter 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 l’état Pattern, subjectivement, il y a des états, comme l’état actuel du patient (par exemple, température élevée ou température basse), sur la base du prochain plan d’action (prescription de médicaments). Et un état peut conduire à un autre état. pour déclarer la dépendance (composition technique).

Si nous essayons techniquement de le comprendre, sur la base d’une comparaison de code des deux, nous pourrions perdre la subjectivité de la situation, car les deux semblent très similaires.

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 d’état 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-modèle, si vous voulez. Cela dépend vraiment si vous voulez que les états dérivés contiennent des références au contexte ou non (c.-à-d. Voulez-vous qu’ils appellent des méthodes sur le contexte).

Pour plus d’informations: Robert C Martin (& Micah Martin) répond à cela dans son livre “Principes, modèles et pratiques agiles en C #”. ( http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 )

C’est une question assez ancienne, mais je cherchais toujours 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 de lecteur médial. Lorsque nous jouons, il commence à jouer et met le contexte au courant qu’il joue. Chaque fois que le client souhaite effectuer une opération de lecture, il vérifie l’état actuel du lecteur. Maintenant, le client sait que l’état de l’object est lu via l’object de contexte. Il appelle donc la méthode des actions des objects d’état de pause. La partie du client réalisant l’état et l’état dans lequel elle 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 faire des opérations. C’est-à-dire qu’au lieu des différents états, il existe différents algorithmes, par exemple différentes parsings à effectuer sur le motif. Ici, les clients indiquent au contexte ce qu’il veut faire, quel algorithme (algorithme personnalisé défini par l’entreprise), puis l’exécutent.

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

Les deux implémentent un principe de fermeture ouvert pour que le développeur ait la possibilité d’append 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 le modèle d’état utilisé pour exécuter une logique différente basée sur un état de l’object. Et dans un cas de stratégie différente logique.

State est livré avec un peu de dépendances dans les classes dérivées des états: comme un état connaît les autres états à venir. Par exemple, Summer vient après l’hiver pour tout état de saison, ou État de livraison après l’état de repository pour les achats.

D’autre part, 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 schéma de stratégie pour permettre à différents algorithmes d’être choisis dans un cadre global d’parsing des données. Grâce à cela, vous pouvez append des algorithmes sans avoir à modifier les frameworks généraux et leur logique.

Un exemple typique est que vous avez un cadre pour optimiser une fonction. Le framework met en place les données et les parameters. Le modèle de stratégie vous permet de sélectionner des algorithmes tels que les descentes de sttepest, les gradients de conjugaison, les BFGS, etc. sans modifier le cadre.

Le modèle Stratégie et État a la même structure. Si vous regardez le diagramme de classes UML pour les deux patterns, ils ont exactement la même apparence, 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 object, tandis que le modèle de stratégie est utilisé pour définir un ensemble d’algorithmes interchangeables et permet au client d’en choisir un. Donc, le modèle de stratégie est un modèle piloté par le client alors que Object peut gérer lui-même son état.

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