Quel est le modèle de stratégie des modèles de conception Java ?

Strategy Pattern

Aussi connu sous le nom de : Strategy

Intent

Strategy Pattern est un modèle de conception comportemental qui vous permet de définir une série d'algorithmes et de placer chaque algorithme dans une classe distincte, de sorte que les objets de l’algorithme peuvent être remplacés les uns par les autres.

Question

Un jour, vous envisagez de créer un programme de guides touristiques pour les touristes. La fonctionnalité principale du programme est de fournir de belles cartes pour aider les utilisateurs à s'orienter rapidement dans n'importe quelle ville.

Une nouvelle fonctionnalité de l'application que les utilisateurs attendent avec impatience est la planification automatique d'itinéraire : ils souhaitent saisir une adresse et voir l'itinéraire le plus rapide vers leur destination sur une carte.

La première version du programme ne peut planifier que des itinéraires routiers. Les personnes voyageant en voiture en sont très satisfaites. Mais évidemment, tout le monde ne conduit pas en vacances. Vous avez donc ajouté la possibilité de planifier des itinéraires de randonnée dans votre prochaine mise à jour. Depuis, vous avez ajouté la possibilité de planifier des itinéraires de transports en commun.

Et ce n'est que le début. Bientôt, vous planifierez des itinéraires pour les cyclistes. Au bout d'un moment, il faut à nouveau planifier son itinéraire pour visiter toutes les attractions de la ville.

Le code du guide deviendra très gonflé.

Bien que cette application soit très réussie d'un point de vue commercial, sa partie technique vous donne un énorme mal de tête : chaque fois qu'un nouvel algorithme de planification d'itinéraire est ajouté, la taille des classes principales dans l'application de guide touristique double. Finalement à un moment donné, vous sentez que vous ne pouvez plus maintenir cette pile de code.

Qu'il s'agisse de corriger une simple faille ou d'affiner les poids de rue, toute modification d'un algorithme affecte l'ensemble de la classe, augmentant le risque d'introduire des bugs dans un code déjà fonctionnel.

De plus, le travail d’équipe deviendra inefficace. Si vous recrutez des membres de l'équipe après la sortie réussie de l'application, ils se plaindront du temps passé à travailler sur les conflits de fusion. Lors du processus d'implémentation de nouvelles fonctionnalités, votre équipe doit modifier la même énorme classe, de sorte que le code qu'elle écrit peut entrer en conflit les uns avec les autres.

Solution

Le modèle Stratégie suggère d'identifier les classes responsables de l'accomplissement d'une tâche spécifique de différentes manières, puis d'extraire les algorithmes qu'elles contiennent dans un ensemble de classes indépendantes appelées stratégies.

La classe d'origine nommée context doit contenir une variable membre pour stocker une référence à chaque stratégie. Le contexte n'effectue pas la tâche, mais délègue le travail à l'objet de stratégie connecté.

Le contexte n'est pas responsable de la sélection de l'algorithme qui répond aux besoins de la tâche - le client transmettra la stratégie requise au contexte. En fait, le contexte ne sait pas grand-chose des stratégies, il interagit avec toutes les stratégies via la même interface commune, qui n'a qu'à exposer une méthode pour déclencher l'algorithme encapsulé dans la stratégie sélectionnée.

Ainsi, le contexte peut être indépendant de stratégies spécifiques. Cela vous permet d'ajouter de nouveaux algorithmes ou de modifier ceux existants sans changer le code contextuel ou d'autres stratégies.

Stratégies de planification d'itinéraire.

Dans une application de guide touristique, chaque algorithme de planification d'itinéraire peut être extrait dans une classe distincte avec une seule méthode de build­Routegénération d'itinéraire. Cette méthode reçoit les points de départ et d'arrivée en tant que paramètres et renvoie une collection de points médians d'itinéraire.

Même si les paramètres transmis à chaque classe de planification d'itinéraire sont exactement les mêmes, les itinéraires créés peuvent être complètement différents. La tâche principale de la classe principale de guide touristique est de restituer une série de points à mi-chemin sur la carte et ne se soucie pas de la façon dont l'algorithme est choisi. Il existe également une méthode dans cette classe pour changer la stratégie de planification de chemin actuelle, de sorte que le client (comme un bouton dans l'interface utilisateur) peut remplacer le comportement de planification de chemin actuellement sélectionné par une autre stratégie.

Analogies du monde réel

Diverses stratégies de voyage à l'aéroport

Si vous devez vous rendre à l'aéroport. Vous pouvez choisir de prendre un bus, de réserver un taxi ou de faire du vélo. Ce sont vos stratégies de voyage. Vous pouvez choisir l'une de ces stratégies en fonction de facteurs tels que le budget ou le temps.

Strategy Pattern Structure

• Context (Context) maintient une référence à une stratégie spécifique et communique avec cet objet uniquement via l'interface de stratégie. L'interface

• Strategy (Strategy) est une interface commune à toutes les stratégies spécifiques. Elle déclare une méthode contextuelle pour exécuter la stratégie.

• Concrete Strategies mettent en œuvre différentes variantes de l'algorithme utilisé par le contexte.

• Lorsque le contexte doit exécuter un algorithme, il appelle la méthode d'exécution sur son objet de stratégie connecté. Le contexte n’est pas clair quant au type de stratégie impliquée et à la manière dont l’algorithme est exécuté.

• Client(Client) crée un objet de stratégie spécifique et le transmet au contexte. Le contexte fournit un paramètre permettant au client de remplacer la stratégie associée au moment de l'exécution.

Pseudocode

Dans cet exemple, le contexte utilise plusieurs stratégies pour effectuer différentes opérations de calcul.

// 策略接口声明了某个算法各个不同版本间所共有的操作。上下文会使用该接口来
// 调用有具体策略定义的算法。
interface Strategy is
    method execute(a, b)
// 具体策略会在遵循策略基础接口的情况下实现算法。该接口实现了它们在上下文
// 中的互换性。
class ConcreteStrategyAdd implements Strategy is
    method execute(a, b) is
        return a + b
class ConcreteStrategySubtract implements Strategy is
    method execute(a, b) is
        return a - b
class ConcreteStrategyMultiply implements Strategy is
    method execute(a, b) is
        return a * b
// 上下文定义了客户端关注的接口。
class Context is
    // 上下文会维护指向某个策略对象的引用。上下文不知晓策略的具体类。上下
    // 文必须通过策略接口来与所有策略进行交互。
    private strategy: Strategy
    // 上下文通常会通过构造函数来接收策略对象，同时还提供设置器以便在运行
    // 时切换策略。
    method setStrategy(Strategy strategy) is
        this.strategy = strategy
    // 上下文会将一些工作委派给策略对象，而不是自行实现不同版本的算法。
    method executeStrategy(int a, int b) is
        return strategy.execute(a, b)
// 客户端代码会选择具体策略并将其传递给上下文。客户端必须知晓策略之间的差
// 异，才能做出正确的选择。
class ExampleApplication is
    method main() is
        创建上下文对象。
        读取第一个数。
        读取最后一个数。
        从用户输入中读取期望进行的行为。
        if (action == addition) then
            context.setStrategy(new ConcreteStrategyAdd())
        if (action == subtraction) then
            context.setStrategy(new ConcreteStrategySubtract())
        if (action == multiplication) then
            context.setStrategy(new ConcreteStrategyMultiply())
        result = context.executeStrategy(First number, Second number)
        打印结果。

Le mode stratégie convient aux scénarios d'application

Lorsque vous souhaitez utiliser diverses variantes d'algorithme dans un objet et que vous souhaitez pouvoir changer d'algorithme au moment de l'exécution, vous pouvez utiliser le mode stratégie.

Le modèle Stratégie vous permet de modifier indirectement le comportement des objets au moment de l'exécution en associant des objets à différents sous-objets qui peuvent effectuer des sous-tâches spécifiques de différentes manières.

Utilisez le modèle Stratégie lorsque vous avez de nombreuses classes similaires qui ne diffèrent que légèrement dans l'exécution de certains comportements.

Le modèle Stratégie vous permet d'extraire différents comportements dans une hiérarchie de classes distincte et de combiner les classes d'origine en une seule, réduisant ainsi la duplication de code.

Si l'algorithme n'est pas particulièrement important dans la logique du contexte, l'utilisation de ce modèle peut isoler la logique métier de la classe des détails d'implémentation de son algorithme.

Le modèle de stratégie vous permet d'isoler le code, les données internes et les dépendances de divers algorithmes des autres codes. Différents clients peuvent exécuter des algorithmes via une interface simple et peuvent être commutés au moment de l'exécution.

Ce modèle peut être utilisé lorsque des opérateurs conditionnels complexes sont utilisés dans la classe pour basculer entre différentes variantes du même algorithme.

Le modèle de stratégie extrait tous les algorithmes hérités de la même interface dans des classes indépendantes, les instructions conditionnelles ne sont donc plus nécessaires. L'objet primitif n'implémente pas toutes les variantes de l'algorithme, mais délègue l'exécution à l'un des objets algorithmiques individuels.

Implémentation

• Découvrez l'algorithme le plus fréquemment modifié à partir de la classe de contexte (il peut également s'agir d'un opérateur conditionnel complexe utilisé pour sélectionner une certaine variante d'algorithme au moment de l'exécution).

• Déclare une interface de stratégie commune pour toutes les variantes de cet algorithme.

• Extraire les algorithmes dans leurs classes respectives un par un, et ils doivent tous implémenter l'interface de stratégie.

• Ajoutez une variable membre dans la classe de contexte pour enregistrer une référence à l'objet de stratégie. Fournissez ensuite un setter pour modifier la variable membre. Le contexte ne peut interagir avec l'objet de stratégie que via l'interface de stratégie. Si nécessaire, une interface peut être définie pour permettre à la stratégie d'accéder à ses données.

• Le client doit associer la classe de contexte à la politique correspondante afin que le contexte puisse accomplir sa tâche principale de la manière attendue.

Avantages et inconvénients du mode stratégie

• Vous pouvez changer l'algorithme dans l'objet au moment de l'exécution.

• Vous pouvez isoler l'implémentation de l'algorithme du code qui utilise l'algorithme.

• Vous pouvez utiliser la composition au lieu de l'héritage.

• Principe d'ouverture et de fermeture. Vous pouvez introduire de nouvelles stratégies sans modifier le contexte.

Avantages et inconvénients du modèle de stratégie

• Si votre algorithme change rarement, il n'y a aucune raison d'introduire de nouvelles classes et interfaces. L'utilisation de ce modèle ne fera que rendre le programme trop complexe.

• Le client doit connaître la différence entre les stratégies - il doit choisir la stratégie appropriée.

• De nombreux langages de programmation modernes prennent en charge la fonctionnalité de type de fonction, vous permettant d'implémenter différentes versions d'un algorithme dans un ensemble de fonctions anonymes. De cette façon, vous utilisez ces fonctions exactement de la même manière que vous utilisez l'objet de stratégie, sans avoir à recourir à des classes et des interfaces supplémentaires pour garder votre code simple.

Relation avec d'autres modèles

Les interfaces des modèles Bridge, Stateful et Strategy (et dans une certaine mesure Adapter) sont très similaires. En fait, ils sont tous basés sur le modèle de composition, c'est-à-dire en déléguant le travail à d'autres objets, mais chacun résout des problèmes différents. Les modèles ne sont pas seulement des recettes pour organiser le code d'une manière spécifique ; vous pouvez également les utiliser pour discuter des problèmes qu'ils résolvent avec d'autres développeurs.

Les modèles et stratégies de commandes se ressemblent car les deux peuvent paramétrer des objets avec certains comportements. Leurs intentions sont cependant très différentes.

• Vous pouvez utiliser des commandes pour convertir n'importe quelle opération en objet. Les paramètres de l'opération deviendront des variables membres de l'objet. Vous pouvez utiliser des transformations pour retarder l'exécution d'opérations, mettre des opérations en file d'attente, enregistrer des commandes historiques ou envoyer des commandes à des services distants.

• Les stratégies, en revanche, peuvent souvent être utilisées pour décrire différentes façons d'accomplir quelque chose, vous permettant de changer d'algorithme au sein de la même classe de contexte.

Le mode Décoration vous permet de changer l'apparence d'un objet, tandis que les stratégies vous permettent de changer son essence.

Le modèle de méthode template est basé sur le mécanisme d'héritage : il permet de modifier une partie de l'algorithme en étendant une partie du contenu dans la sous-classe. Les stratégies sont basées sur un mécanisme de composition : vous pouvez modifier une partie du comportement d'un objet en proposant différentes stratégies pour le comportement correspondant. Les méthodes de modèle fonctionnent au niveau de la classe, elles sont donc statiques. Les politiques fonctionnent au niveau de l'objet, permettant ainsi de modifier le comportement au moment de l'exécution.

Les États peuvent être pensés comme une extension de la stratégie. Tous deux sont basés sur des mécanismes de composition : ils modifient tous deux son comportement dans différentes situations en déléguant une partie du travail à des objets « assistants ». La politique rend ces objets complètement indépendants les uns des autres et ils ignorent l'existence d'autres objets. Cependant, le modèle d’état ne limite pas les dépendances entre états spécifiques et leur permet de changer d’état selon différents scénarios.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!