Quelle est la différence entre le modèle de conception Stratégie et le modèle de conception État?
Quelles sont les différences entre le modèle de conception Strategy et le modèle de conception State? Je passais en revue plusieurs articles sur le Web, mais je ne pouvais pas faire la différence clairement.
Quelqu'un peut-il s'il vous plaît expliquer la différence dans les termes du profane?
Honnêtement, les deux modèles sont assez similaires dans la pratique et la différence qui les différencie tend à varier en fonction de la personne à qui vous le demandez. Certains choix populaires sont:
- Les états stockent une référence à l'objet de contexte 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 de contexte en quelque chose d'autre), alors que les stratégies ne le sont pas.
- Les stratégies sont transmises à l'objet de contexte en tant que paramètres, tandis que les états sont créés par l'objet de contexte 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) que l'objet de contexte fait.
Une implémentation "classique" correspondrait à l'état ou à la stratégie pour chaque élément de la liste, mais vous rencontrez des hybrides combinant les deux. La question de savoir si un État particulier est plus politique ou stratégique est en définitive une question subjective.
- Le modèle Stratégie consiste en réalité à avoir une implémentation différente qui réalise (essentiellement) la même chose, de sorte qu'une implémentation puisse remplacer l'autre si la stratégie l'exige. Par exemple, vous pouvez avoir différents algorithmes de tri dans un modèle de stratégie. Les appelants de 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 État consiste à faire différentes choses en fonction de l'état, tout en laissant l'appelant soulagé du fardeau de la gestion de tous les états possibles. Ainsi, par exemple, vous pourriez avoir une méthode
getStatus()qui retournera différents statuts en fonction de l'état de l'objet, mais l'appelant de la méthode n'aura pas à ê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 le type quoi (état ou type) d'un objet (en) - il encapsule le comportement dépendant de l'état , tandis que
- le modèle Strategy traite comment un objet exécute une tâche donnée - il encapsule un algorithme.
Les constructions 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 le modèle State , la classe détenteur d'état (context) est dégagée de la connaissance de quoi state ou du type qu'il est et quels états ou types sont disponibles. Cela signifie que la classe adhère au principe de conception ouvert-fermé (OCP): la classe est fermée en cas de modification des états/types existants, mais les états/types sont ouverts aux extensions.
En utilisant le modèle Strategy , la classe utilisant un algorithme (contexte) est dégagée de la connaissance de comment pour effectuer une tâche donnée ( - "l'algorithme"). Cette affaire crée également une adhésion à l'OCP; la classe est fermée aux modifications concernant l'exécution de cette tâche, mais la conception est très ouverte aux ajouts d'autres algorithmes permettant de résoudre cette tâche.
Cela améliore probablement également l'adhésion de la classe de contexte au principe de responsabilité unique (SRP). De plus, 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 design ne sont pas vraiment des concepts "laïcs", mais je vais essayer de le rendre aussi clair que possible. Tout modèle de conception peut être considéré en trois dimensions:
- Le problème que le modèle résout;
- La structure statique du motif (diagramme de classes);
- La dynamique du motif (diagrammes de séquence).
Comparons État et stratégie.
Problème résolu par le motif
State 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 de 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 contiendront cette même structure conditionnelle. Le modèle d'état 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 pouvant 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 devriez pouvoir modéliser les états de l'objet à l'aide de la machine à états finite. Vous pouvez trouver un exemple appliqué ici .
Chaque transition d'état est une méthode de l'interface d'état. Cela implique que pour un design, 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 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 recherche (ce n'est pas un moyen OO, mais cela fonctionne plutôt bien).
La stratégie est utilisée pour ce qui suit [Livre du GoF p. 316] :
- beaucoup de classes lié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 classe 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, spécifiques à un algorithme.
- une classe définit de nombreux comportements, qui apparaissent sous forme d'instructions conditionnelles multiples 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 d'application de Strategy est lié à une refactorisation appelée Remplacer conditionnellement par polymorphisme .
Résumé: État 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, il est probable que le modèle d'état ne soit 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
State a la structure de classe UML suivante:
Strategy 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 motif tels que celui-ci considèrent que " la structure des motifs [...] est identique, interdisant leur distinction par un processus automatique (par exemple, informations conceptuelles). "
Cependant, il peut 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 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, Etat implique que le comportement change au moment de l'exécution en fonction de certains state d'un objet. Par conséquent, la notion d'état transitioning s'applique, comme indiqué dans 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 simple machine à états finis:
En supposant que les sous-classes décident de la transition d'état (en renvoyant le prochain objet state), la dynamique ressemble à ceci:
Pour montrer la dynamique de 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 du prochain état. Dans le modèle de stratégie, l’appel polymorphe ne modifie généralement pas le contexte (par exemple, payer une seule fois par carte de crédit ne signifie pas que vous paierez par Paypal la prochaine fois). Encore une fois, la dynamique du modèle d'état est déterminée par la machine à états correspondante fininte,, qui (selon 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 d'une classe d'hébergement et à le placer dans une classe séparée. Cela signifie que la classe hôte n'a pas besoin de fournir l'implémentation de chaque algorithme lui-même, ce qui peut conduire à un code non propre.
Les algorithmes de tri sont généralement utilisés à titre d'exemple car ils font tous le même genre de choses (tri). Si chaque algorithme de tri 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 objet lorsque son état change. Cela signifie que la classe Host n'a pas fourni l'implémentation du comportement pour tous les états possibles. La classe Host encapsule généralement une classe qui fournit la fonctionnalité requise dans un état donné et passe à une autre classe. quand l'état change.
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 à la représentation de 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.
Prenons un système de réponse vocale interactive (IVR) gérant les appels des clients. Vous voudrez peut-être le programmer pour gérer les clients sur:
- jours de travail
- Vacances
Pour gérer cette situation, vous pouvez utiliser un State Pattern.
- Holiday: L'IVR répond simplement en disant que ' Les appels ne peuvent être passés que les jours ouvrables entre 9h et 17h '.
- jours ouvrables: il répond en connectant le client à un responsable du service clientèle.
Ce processus de connexion d'un client à un responsable de support peut lui-même être mis en œuvre à l'aide d'un modèle de stratégie, dans lequel les responsables sont sélectionnés en fonction de:
- Round Robin
- moins utilisé récemment
- Autres algorithmes basés sur la priorité
Le modèle de stratégie décide "comment" pour exécuter une action et le modèle d'état détermine "quand" pour les exécuter.
Stratégie: la stratégie est fixe et comprend généralement plusieurs étapes. (Le tri 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", "méthode principale" correspond à goThroughDoor (), qui ressemble à ceci :approcheDoor (), 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 peuvent implémenter les étapes de l'algorithme.
En d'autres termes, la sous-classification de la stratégie ne modifie pas les algorithmes de base, mais uniquement des étapes individuelles.
CE CI-DESSUS est un modèle de méthode de modèle. À présent, regroupez les étapes (déverrouillage/verrouillage et ouverture/fermeture) dans leurs propres objets de mise en œuvre et déléguez-les. Par exemple. une serrure avec une clé et une serrure avec une carte à code sont deux types de serrures. Déléguez de la stratégie aux objets "Step". Maintenant, vous avez un modèle de stratégie.
Un modèle d'état est quelque chose de complètement différent.
Vous avez un objet wrapping et l'objet wrapped. Celui qui est enveloppé est "l'état". L'objet state est uniquement accessible via son wrapper. Vous pouvez maintenant modifier l'objet enveloppé à tout moment. Le wrapper semble donc changer d'état ou même de "classe" ou de type.
Par exemple. vous avez un service de connexion. Il accepte un nom d'utilisateur et un mot de passe. Il n'y a qu'une méthode: la connexion (String userName, String 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 objet state. En général, cet objet d'état vérifie simplement si la combinaison utilisateur/passe est valide et effectue une connexion. Mais maintenant, vous pouvez échanger le "Checker" par un autre permettant uniquement aux utilisateurs privilégiés de se connecter (par exemple, pendant la période de maintenance) ou par un autre ne permettant à aucun utilisateur de se connecter. 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 suivez 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 la stratégie. OTOH dans une situation de modèle d'état pendant l'exécution de votre système, vous modifiez l'état de façon arbitraire, à votre convenance.
Stratégie Le modèle est utilisé lorsque vous avez plusieurs algorithmes pour une tâche spécifique et que le client décide de la mise en œuvre réelle. être utilisé au moment de l'exécution.
Diagramme UML de wiki Article de modèle de stratégie:
Caractéristiques principales:
- C'est un modèle de comportement.
- C'est basé sur la délégation.
- Il change les entrailles de l'objet en modifiant le comportement de la méthode.
- Il est utilisé pour basculer entre les familles d'algorithmes.
- Cela change le comportement de l'objet au moment de l'exécution.
Reportez-vous à ce post pour plus d'informations et d'exemples concrets:
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 wiki Article de modèle d'état:
Si nous devons modifier 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 conditions 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 en mode découplé d'y parvenir via Contexte et Etat implémentations.
Reportez-vous à cet article journaldev pour plus de détails.
Principales différences par rapport à création de source et journaldev articles:
- La différence entre État et Stratégie réside dans le temps de reliure. La stratégie est un modèle bind-once, tandis que l'état est plus dynamique .
- La différence entre État et Stratégie est dans l'intention. Avec Strategy, le choix de l'algorithme est relativement stable . Avec State, un changement d'état de l'objet "context" entraîne sa sélection dans sa "palette" d'objets Strategy .
- Le contexte contient l'état en tant que variable d'instance et il peut y avoir plusieurs tâches dont la mise en œuvre peut dépendre de l'état , alors que dans stratégie modèle stratégie est passé en tant qu'argument à la méthode et l'objet context n'a pas d'objet variable pour le stocker.
En langage profane,
dans le modèle de stratégie, il n'y a pas d'états ou tous ont le même état. Tout le monde a différentes façons d'accomplir une tâche, comme si différents médecins traitaient 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, tels que l'état actuel du patient (par exemple, température élevée ou basse température), en fonction desquels la prochaine action à prendre (prescription de médicament) sera décidée. Un état peut conduire à un autre état, indiquer la dépendance (composition technique).
Si nous essayons techniquement de le comprendre, en comparant les codes des deux, nous risquons de perdre la subjectivité de la situation, car ils se ressemblent beaucoup.
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 Lecture du lecteur multimédia. Lorsque nous jouons, il commence à jouer et rend le contexte conscient du fait qu'il joue. Chaque fois que le client souhaite effectuer une opération de lecture, il vérifie l'état actuel du lecteur. À présent, le client sait que l'état de l'objet est en cours de lecture via l'objet context. Il appelle donc la méthode des actions des objets d'état de pause. La partie du client qui réalise l’état et l’état sur lequel il doit agir peuvent être automatisées.
https://www.youtube.com/watch?v=e45RMc76884https://www.tutorialspoint.com/design_pattern/state_pattern.htm
Dans le cas d'un 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 une opération. C’est-à-dire qu’à la place des différents états, différents algorithmes indiquent, par exemple, différentes analyses à effectuer sur le motif. Ici, les clients indiquent au contexte ce qu’ils veulent faire, quel algorithme (algorithme personnalisé défini par l’entreprise), puis le met en œuvre.
https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm
Les deux implémentent le principe d'ouverture/fermeture afin que le développeur puisse ajouter de nouveaux états au modèle d'état et au nouvel algorithme.
Mais la différence réside dans leur modèle d’état utilisé pour exécuter une logique différente en fonction de l’état de l’objet. Et dans un cas de stratégie différente logique.
Les deux modèles délèguent à une classe de base comportant plusieurs dérivés, mais ce n'est que dans le modèle d'état que ces classes dérivées retiennent une référence à la classe de contexte.
Une autre façon de voir les choses est que le modèle Strategy est une version plus simple du modèle State; un sous-motif, si vous aimez. Cela dépend vraiment si vous voulez que les états dérivés retiennent les références au contexte ou pas (c'est-à-dire, voulez-vous qu'ils appellent des méthodes sur le contexte).
Pour plus d’informations: Robert C Martin (et Micah Martin) répondent à cela dans leur livre "Principes, habitudes et pratiques agiles en C #". ( http://www.Amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 )
L'état comporte quelques dépendances au sein des classes dérivées d'état: comme un état le sait, d'autres états le suivent. Par exemple, l'été intervient après l'hiver, quel que soit l'état de la saison, ou l'état de livraison après l'état du dépôt pour les achats.
D'autre part, la stratégie 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 à différents algorithmes d'être choisis dans un cadre global d'analyse de données. Grâce à cela, vous pouvez ajouter des algorithmes sans avoir à changer les cadres globaux et leur logique.
Un exemple typique est que vous avez 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 des descentes de sttepest, des gradients conjugués, BFGS, etc. sans modifier le cadre.
La stratégie et le modèle d'état ont la même structure. Si vous examinez le diagramme de classes UML pour les deux modèles, 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 objet, tandis que le modèle de stratégie permet de 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 basé sur le client, tandis que Object peut gérer son état lui-même.
En bref, 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 objet changera de comportement en interne avec le changement d'é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 à réaliser: 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 de 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 modifier l'objet d'état de l'état 1 à l'état 2. Ensuite, votre tâche sera accomplie par alg2 et alg5, au lieu de alg1 et alg3.
Vous pouvez ajouter d'autres algorithmes interchangeables pour la tâche 1 ou la tâche 2. Il s'agit d'un modèle de stratégie.
Vous pouvez avoir plus d'états avec une combinaison différente d'algorithmes dans les tâches 1 et 2. Le modèle d'état vous permet de passer d'un état à un autre et d'effectuer différentes combinaisons d'algorithmes.