Différence entre les modèles d'état et de stratégie en Java

Afin d'utiliser correctement les modèles d'état et de stratégie dans les applications Java principales, il est important que les programmeurs Java comprennent clairement la différence entre eux. Bien que les deux modèles, État et Stratégie, aient une structure similaire et soient tous deux basés sur le principe ouvert/fermé, représentant le « O » dans les principes SOLID , leur intention est complètement différente . Le modèle de stratégie en Java est utilisé pour encapsuler des ensembles d'algorithmes associés afin de fournir une flexibilité d'exécution au client. Le client peut choisir n'importe quel algorithme au moment de l'exécution sans modifier le contexte de la classe qui utilise le Strategy. Certains exemples populaires du modèle Strategy sont l’écriture de code qui utilise des algorithmes, tels que le chiffrement, la compression ou le tri. D’un autre côté, le modèle State permet à un objet de se comporter différemment selon les états. Parce que dans le monde réel, un objet a souvent des états et il se comporte différemment selon les états, par exemple, un distributeur automatique ne vend des marchandises que s'il se trouve dans l'état hasCoin, il ne se vend pas tant que vous n'y mettez pas une pièce. Vous pouvez maintenant voir clairement la différence entre les modèles Stratégie et État, ce sont des intentions différentes. Le modèle State aide un objet à gérer son état, tandis que le modèle Strategy permet au client de choisir un comportement différent. Une autre différence qui n’est pas si facile à voir est de savoir qui est à l’origine du changement de comportement. Dans le cas du modèle Strategy, il s'agit d'un client qui fournit diverses stratégies au contexte ; dans le modèle State, la transition est contrôlée par le contexte ou l'état de l'objet lui-même. De plus, si vous gérez vous-même les changements d'état dans l'objet State, il doit y avoir une référence au contexte, par exemple, un distributeur automatique doit pouvoir appeler une méthode setState()pour modifier l'état actuel du contexte. En revanche, l'objet Stratégie ne contient jamais de référence au contexte ; le client lui-même transmet la Stratégie de son choix au contexte. La différence entre les modèles d'état et de stratégie est l'une des questions d'entretien les plus populaires sur les modèles Java . Dans cet article sur les modèles Java, nous l'examinerons de plus près. Nous explorerons certaines similitudes et différences entre les modèles de stratégie et d'état en Java qui vous aideront à améliorer votre compréhension de ces modèles.

Similitudes entre les modèles d’État et de stratégie

Si vous regardez le diagramme UML des modèles d'état et de stratégie, vous remarquerez que les deux se ressemblent. Un objet qui utilise State pour modifier son comportement est appelé Context-object, de même qu'un objet qui utilise Strategy pour modifier son comportement est appelé Context-object. N'oubliez pas que le client interagit avec Contextl'objet. Dans le cas du modèle State, le contexte délègue les méthodes d'appel à un objet State, qui est conservé comme objet actuel, et dans le cas du modèle Strategy, le contexte utilise l'objet Strategy comme paramètre ou est fourni lors de la création. du contexte de l'objet. Diagramme UML du modèle State en Java Ce diagramme UML pour le modèle State décrit le problème classique de la création d'une conception de distributeur automatique orientée objet en Java. Vous pouvez voir que l'état du distributeur automatique est représenté à l'aide d'une interface, qui dispose ensuite d'une implémentation pour représenter l'état spécifique. Chaque état possède également des références au contexte de l'objet pour effectuer une transition vers un autre état à la suite d'actions appelées dans le contexte. Diagramme UML du modèle Strategy en Java Ce diagramme UML pour le modèle Strategy contient diverses implémentations fonctionnelles. Puisqu'il existe de nombreux algorithmes de tri, ce modèle de conception permet au client de choisir un algorithme lors du tri des objets. En fait, le framework Java Collection utilise ce modèle pour implémenter une méthode Collections.sort()utilisée pour trier les objets en Java. La seule différence est qu'au lieu de permettre au client de choisir un algorithme de tri, cela lui permet de spécifier la stratégie de comparaison en passant une instance de l' interface Comparator ou Comparable à Java . Examinons quelques similitudes entre ces deux modèles de conception majeurs en Java :

1. Les deux modèles, State et Strategy, facilitent l'ajout de nouveaux états et stratégies sans affecter le contexte de l'objet qui les utilise.


2. Ces deux éléments maintiennent votre code selon le principe ouvert/fermé , ce qui signifie que la conception sera ouverte aux extensions mais fermée à la modification. Dans le cas des modèles État et Stratégie, le contexte de l'objet est fermé aux modifications, à l'introduction de nouveaux États ou de nouvelles Stratégies, ou vous n'avez pas besoin de modifier le contexte de l'autre état, ni de changements minimes.


3. Tout comme un contexte d'objet commence par l'état d'initialisation de l'objet dans le modèle State, un contexte d'objet a également une stratégie par défaut dans le cas du modèle Strategy en Java.


4. Le modèle État représente différents comportements sous la forme de différents états d'objet, tandis que le modèle Stratégie représente différents comportements sous la forme de différentes stratégies d'objet.


5. Les deux modèles, Stratégie et État, dépendent de sous-classes de mise en œuvre du comportement. Chaque stratégie concrète étend une stratégie abstraite ; chaque état est une sous-classe d’une interface ou d’une classe abstraite utilisée pour représenter l’État.

Différences entre les modèles de stratégie et d'état en Java

Nous savons maintenant que les modèles d’État et de stratégie ont une structure similaire, mais que leur intention est différente. Examinons quelques différences clés entre ces modèles de conception.

1. Le modèle Strategy encapsule un ensemble d'algorithmes associés et permet au client d'utiliser des comportements interchangeables malgré la composition et la délégation au moment de l'exécution. D'autre part, le modèle State aide une classe à présenter des comportements différents dans différents états.


2. La différence suivante entre les modèles d'état et de stratégie est que l'état encapsule l'état d'un objet, tandis que le modèle de stratégie encapsule un algorithme ou une stratégie. Puisque l'état est associé à un objet, il ne peut pas être réutilisé, mais en découplant une stratégie ou un algorithme de son contexte, nous pouvons le réutiliser.


3. Dans le modèle State, un état personnel peut contenir une référence au contexte pour mettre en œuvre des transitions entre les états, mais une stratégie ne contient pas de référence au contexte dans lequel elle est utilisée.


4. L'implémentation d'une Stratégie peut être passée en paramètre à l'objet qui va l'utiliser, par exemple Collection.sort() prend un Comparator qui est une stratégie. D'un autre côté, l'état fait partie du contexte lui-même de l'objet et, au fil du temps, le contexte de l'objet passe d'un état à un autre.


5. Bien que la stratégie et l'État suivent le principe ouvert/fermé, la stratégie suit également le principe de responsabilité unique puisque chaque stratégie contient un algorithme individuel, les différentes stratégies sont indépendantes les unes des autres. Changer une stratégie ne nécessite pas de changer une autre stratégie.


6. Une autre différence théorique entre les modèles Stratégie et État est que le créateur définit la partie « Comment » de l'objet, par exemple « Comment » l'objet de tri trie les données, tandis que le modèle État définit le « quoi » et le « quand ». parties de l'objet, par exemple ce qu'un objet peut faire lorsqu'il est dans un certain état.


7. L'ordre des transitions d'état est bien défini dans le modèle État ; il n'y a pas une telle exigence pour le modèle Stratégie. Le Client est libre de choisir toute mise en œuvre de la Stratégie de son choix.


8. Certains des exemples courants de modèle de stratégie sont l'encapsulation d'algorithmes, tels que des algorithmes de tri, des algorithmes de chiffrement ou un algorithme de compression. Si vous constatez que votre code doit utiliser différents types d’algorithmes associés, vous devriez envisager d’utiliser le modèle Strategy. D'un autre côté, reconnaître l'utilisation du modèle State est assez simple, si vous avez besoin de gérer des états et des transitions d'état sans beaucoup d'instructions conditionnelles imbriquées, le modèle State est le bon modèle à utiliser.


9. La dernière mais l'une des différences les plus importantes entre les modèles State et Strategy est qu'un changement vers Strategy est effectué par le client, tandis qu'un changement vers State peut être effectué par le contexte ou l'état de l'objet lui-même.

Tout dépend de la différence entre les modèles State et Strategy en Java . Comme je l'ai dit, les deux se ressemblent dans leurs classes et leurs diagrammes UML, tous deux fournissent des principes ouverts/fermés et encapsulent le comportement. Utilisez le modèle Strategy pour encapsuler un algorithme ou une stratégie exposée au contexte au moment de l'exécution, peut-être en tant que paramètre ou objet composite, et utilisez le modèle State pour contrôler les transitions d'état en Java. Original ici