Mode stratégie de programmation en mode Delphi
Liu Yi
1.1 Explication des modes
Le but du modèle Strategy est de définir un ensemble d'algorithmes et d'encapsuler chaque algorithme dans une classe indépendante avec une interface commune afin qu'ils puissent être remplacés les uns par les autres. Le modèle de stratégie permet des changements d'algorithme indépendamment du client qui l'utilise. Pour comprendre la motivation et l’importance de l’utilisation du modèle de stratégie, nous devons commencer par un exemple intéressant. Dans un système de gestion du matériel, les modules sortants et entrants sont les éléments essentiels du système (nous prendrons le sortant comme exemple pour l'analyse ci-dessous). Pour les programmeurs qui n'ont aucune expérience en programmation orientée objet, ils mettent souvent toute la logique de la commande sortante sur le client (interface de commande de sortie) et utilisent des instructions de branchement conditionnelles sur le client pour déterminer si le type de commande sortante est une préparation. emprunter des matériaux ou déclarer les pertes, afin de choisir différentes méthodes de règlement sortant, comme le montre la figure 1-1. En conséquence, le code du client devient complexe et difficile à maintenir. Par exemple : lorsque vous devez ajouter un nouveau type d'ordre de transfert hors de l'entrepôt, vous devez modifier les conditions de jugement, recompiler et publier le client. À mesure que la situation devient de plus en plus complexe, il y aura de plus en plus de branches conditionnelles et de plus en plus de codes de programme seront ajoutés. Cela rendra le client plus grand et plus difficile à maintenir, et la possibilité d'influence mutuelle et d'erreurs augmentera. . Figure 1-1 Le module sortant conçu sur la base d'une réflexion orientée processus. S'ils sont analysés à l'aide d'une pensée orientée objet, la liste de prélèvement, la liste d'emprunt et le rapport de perte peuvent être considérés comme des classes dérivées du billet sortant, comme le montre la figure 1-. 2 Afficher. De cette manière, le document sortant sert de classe de base de document pour fournir une interface commune aux documents, et l'héritage est utilisé pour implémenter différents comportements sortants dans les sous-classes. Cela utilise en fait un concept important en orienté objet : le polymorphisme. Mais cette conception présente encore un inconvénient : l’environnement et le comportement sont étroitement liés. En d’autres termes, le document et l’algorithme sortant spécifique sont étroitement liés. Un couplage fort empêche les deux d'évoluer indépendamment, ce qui limite la réutilisabilité et l'évolutivité. La figure 1-3 est le module sortant repensé à l'aide du modèle de stratégie. L'objet document sortant fait référence à l'objet politique sortant via un objet opération sortante (c'est-à-dire le contexte en mode stratégie). Diverses stratégies sortantes spécifiques sont mises en œuvre par des classes dérivées de la classe de stratégie sortante. Le document sortant peut fournir une méthode de règlement sortant et une interface d'affichage de document par opération sortante et style de document respectivement. De cette manière, le mode stratégie sépare le comportement sortant de l'environnement du document sortant, et l'augmentation, la diminution ou la modification de l'algorithme sortant n'affectera pas l'environnement ni le client. Figure 1-2 Module sortant conçu sur la base d'une pensée orientée objet Figure 1-3 Module sortant conçu sur la base d'une pensée de modèle de conception L'avantage du modèle de stratégie est la séparation de l'algorithme et de l'environnement, et les deux peuvent évoluer indépendamment. Pour mieux illustrer les avantages de la séparation des algorithmes et des environnements, nous pourrions tout aussi bien examiner la conception de la figure 1-4. Dans cette conception, il n'y a pas de concept de modules sortants et entrants, car j'abstrait tous les documents sortants/entrants et combine dynamiquement l'interface et le comportement des documents pendant l'exécution. Grâce à la classe d'opérations sortantes/entrantes, différentes classes de comportement peuvent être gérées, interrogées et configurées. Le comportement sortant/entrant abstrait encapsule son algorithme correspondant sous la forme d'une classe de stratégie afin de compléter les opérations de différents types de documents entrants et sortants. Cela améliore évidemment la réutilisabilité et l’évolutivité du système et réduit la difficulté de maintenance. Figure 1-4 L'avantage du modèle de stratégie est la séparation de l'algorithme et de l'environnement. Les deux peuvent évoluer indépendamment. On peut voir que le modèle de stratégie est adapté aux situations suivantes : · Lorsque la différence entre de nombreuses classes liées réside. seulement dans leur comportement. Le modèle Stratégie permet à un objet de choisir dynamiquement un comportement parmi plusieurs. · Lorsqu'il existe plusieurs algorithmes alternatifs pour atteindre un objectif, tels que ceux que vous définissez en fonction de différents compromis (c'est-à-dire en appliquant différentes stratégies). Ces algorithmes spécifiques peuvent être encapsulés dans des classes dérivées de la classe d’algorithmes abstraits et bénéficier de l’interface unifiée de la classe d’algorithmes abstraits. Grâce au polymorphisme, le client peut choisir n'importe quel algorithme spécifique tant qu'il contient un objet d'une classe d'algorithme abstraite. · Lorsqu'un algorithme utilise des données qui ne sont pas disponibles pour le client. L’utilisation du modèle Strategy évite d’exposer des structures de données complexes liées aux algorithmes. En effet, le client n’a pas besoin de connaître les connaissances et les données liées à l’algorithme. · Lorsqu'une définition de classe comporte de nombreux comportements et que plusieurs instructions conditionnelles sont utilisées pour déterminer la sélection de ces comportements. Le modèle de stratégie peut transférer ces comportements aux classes de stratégie spécifiques correspondantes, évitant ainsi de multiples sélections conditionnelles difficiles à maintenir et incarnant des idées de programmation orientée objet.
1.2 Structure et utilisation
La structure du modèle de stratégie est illustrée dans la figure 1-5, qui inclut les participants suivants : · Stratégie abstraite (TStrategy) - déclare une interface commune pour tous les algorithmes pris en charge. TContext utilise cette interface pour appeler des algorithmes définis et encapsulés par TConcreteStrategy. · Stratégie concrète (TConcreteStrategy) - encapsule des algorithmes ou des comportements spécifiques. Implémentez l'interface TStrategy. · Contexte (TContext) – contient une référence à TStrategy. Appelez l'interface TStrategy pour configurer dynamiquement des algorithmes ou des comportements spécifiques. Figure 1-5 Structure du modèle de stratégie Dans le modèle de stratégie, l'algorithme sélectionné est implémenté via l'interaction de TStrategy et TContext. Lorsque l'algorithme est appelé, TContext peut transmettre toutes les données requises par l'algorithme à TStrategy. Alternativement, le TContext peut se transmettre en tant que paramètre à l'opération TStrategy. Lorsqu'un TContext transmet une requête client à son TStrategy, le client crée et transmet généralement un objet TConcreteStrategy au TContext de cette manière, le client interagit uniquement avec le TContext ; Il existe généralement une série de classes TConcreteStrategy parmi lesquelles les clients peuvent choisir. -------------------------------------------------- ---------------------------------------------
D'autres articles connexes et des exemples de codes sources de programme peuvent être téléchargés à partir du site Web de l'auteur : http://www.liu-yi.net
