2.1 État
L'état est un modèle de conception comportemental. Il est utilisé dans les cas où, lors de l'exécution du programme, l'objet doit changer de comportement en fonction de son état.
Le patron se compose de 3 blocs :
Le contexte est une classe dont les objets doivent changer de comportement en fonction de l'état.
L'état est l'interface que chacun des états concrets doit implémenter. Grâce à cette interface, l'objet Context interagit avec l'état en lui déléguant les appels de méthode. L'interface doit contenir des moyens de rétroaction vers l'objet dont le comportement doit être modifié.
Pour cela, un événement est utilisé (modèle Editeur - Abonné). Ceci est nécessaire pour remplacer l'objet d'état lors de l'exécution du programme lorsque des événements se produisent. Il peut y avoir des cas où le contexte lui-même interroge périodiquement l'objet d'état pour une transition.
ConcreteState1, ConcreteState2 - classes d'états concrets. Devrait contenir des informations sur dans quelles conditions et dans quels états l'objet peut passer de l'état actuel. Par exemple, à partir de ConcreteState1, un objet peut aller à ConcreteState2 et ConcreteState3, et de ConcreteState2 à ConcreteState1, et ainsi de suite. L'objet de l'un d'entre eux doit contenir le Contexte lors de sa création.
Par exemple, vous écrivez un jeu où un personnage peut courir, nager et voler. Si votre personnage est entré dans l'eau, il est alors raisonnable de limiter son comportement dans l'eau : maintenant il ne peut pas tirer, mais il a encore quelques actions : nager vers l'avant, vers la droite, vers la gauche, etc.
L'état de votre personnage peut être décrit par un objet State, qui a des méthodes qui peuvent être appelées et qui feront quelque chose. Et une fois que votre personnage est entré dans l'eau, vous changez simplement la référence à un autre objet État à l'intérieur - et il change son état.
2.2 stratégie
La stratégie est un modèle de conception comportementale permettant de définir une famille d'algorithmes, d'encapsuler chacun d'eux et de les rendre interchangeables. Cela vous permet de choisir un algorithme en définissant la classe appropriée.
Le pattern Stratégie vous permet de modifier l'algorithme sélectionné quels que soient les objets clients qui l'utilisent.
Le modèle Stratégie vous permet d'utiliser différentes règles métier ou algorithmes en fonction du contexte. Il est utilisé dans les cas où différents algorithmes doivent être utilisés au même endroit en fonction de l'état actuel du système (ou de son environnement).
Forces:
- encapsulation de la mise en œuvre de divers algorithmes, le système devient indépendant des éventuelles modifications des règles métier ;
- appeler tous les algorithmes d'une manière standard ;
- n'utilisant pas de commutateurs et/ou d'instructions conditionnelles.
Ce modèle est quelque peu similaire au modèle État, mais ici l'accent n'est pas mis sur l'état, mais sur le comportement. Disons qu'un personnage de votre jeu peut changer d'arme. Ensuite, lors du changement d'arme, vous pouvez simplement changer la référence à l'objet qui décrit le fonctionnement de cette arme.
2.3 Méthode du modèle
Classe abstraite (classe abstraite) - définit les opérations abstraites qui sont remplacées dans les héritiers pour implémenter les étapes de l'algorithme ; implémente une méthode de modèle qui définit le squelette de l'algorithme. La méthode de modèle appelle les opérations remplacées et autres définies dans la classe abstraite.
Classe concrète (classe concrète) - implémente les opérations remplacées de la manière nécessaire à la mise en œuvre. La classe Concrète suppose que les étapes invariantes de l'algorithme seront exécutées dans la classe abstraite.
Ce modèle est souvent utilisé en cas de besoin :
- Utilisation unique de la partie invariante de l'algorithme, laissant la partie changeante à la discrétion des héritiers.
- Localisation et isolation du code commun à plusieurs classes pour éviter les doublons.
- Autoriser les héritiers à étendre le code uniquement à certains endroits.
Oui, ce pattern décrit l'utilisation d'un couple : une classe abstraite et son implémentation.
2.4 Chaîne de responsabilité
La chaîne de responsabilité est un modèle de conception comportemental conçu pour organiser les niveaux de responsabilité dans un système.
Le modèle est recommandé pour une utilisation dans des conditions où :
- dans le système développé, il existe un groupe d'objets pouvant traiter des messages d'un certain type;
- tous les messages doivent être traités par au moins un objet système ;
- les messages dans le système sont traités selon le schéma "traitez-le vous-même ou transmettez-le à un autre", c'est-à-dire que certains messages sont traités au niveau où ils ont été reçus, tandis que d'autres sont transmis à des objets d'un autre niveau.
2.5 Souvenir
Keeper (Memento) est un modèle de conception comportemental qui vous permet de corriger et d'enregistrer l'état interne d'un objet sans violer l'encapsulation afin qu'il puisse être restauré ultérieurement dans cet état.
Le modèle Guardian est utilisé lorsque :
- il est nécessaire de sauvegarder un instantané de l'état de l'objet (ou d'une partie de celui-ci) pour une restauration ultérieure ;
- L'interface directe pour obtenir l'état d'un objet expose les détails d'implémentation et rompt l'encapsulation de l'objet.