Quelle est la différence entre la méthode du modèle et les modèles de stratégie?

Quelqu’un peut-il m’expliquer quelle est la différence entre le modèle de méthode du modèle et le modèle de stratégie?

Autant que je sache, ils sont à 99% les mêmes – la seule différence étant que le modèle de méthode du modèle a une classe abstraite comme classe de base alors que la classe de stratégie utilise une interface qui est implémentée par chaque classe de stratégie concrète.

Cependant, en ce qui concerne le client, ils sont consommés exactement de la même manière – est-ce correct?

La principale différence entre les deux réside dans le choix de l’algorithme concret.

Avec le modèle de méthode Template, cela se produit à la compilation en sousclassant le modèle. Chaque sous-classe fournit un algorithme concret différent en implémentant les méthodes abstraites du modèle. Lorsqu’un client appelle des méthodes de l’interface externe du modèle, le modèle appelle ses méthodes abstraites (son interface interne) pour invoquer l’algorithme.

class ConcreteAlgorithm : AbstractTemplate { void DoAlgorithm(int datum) {...} } class AbstractTemplate { void run(int datum) { DoAlgorithm(datum); } virtual void DoAlgorithm() = 0; // abstract } 

En revanche, le modèle de stratégie permet de choisir un algorithme au moment de l’ exécution par confinement . Les algorithmes concrets sont implémentés par des classes ou des fonctions distinctes qui sont transmises à la stratégie en tant que paramètre à son constructeur ou à une méthode de réglage. Quel algorithme est choisi pour ce paramètre peut varier dynamicment en fonction de l’état ou des entrées du programme.

 class ConcreteAlgorithm : IAlgorithm { void DoAlgorithm(int datum) {...} } class Strategy { Strategy(IAlgorithm algo) {...} void run(int datum) { this->algo.DoAlgorithm(datum); } } 

En résumé:

  • Modèle de méthode de modèle: sélection d’algorithme de compilation en sous-classement
  • Modèle de stratégie: sélection de l’ algorithme d’exécution par confinement

Le modèle de modèle est utilisé lorsqu’une opération particulière présente un ou plusieurs comportements invariants pouvant être définis en fonction d’autres comportements primitifs. La classe abstraite définit le ou les comportements invariants, tandis que les classes d’implémentation définissent les méthodes dépendantes.

Dans une stratégie, les implémentations de comportement sont indépendantes – chaque classe d’implémentation définit le comportement et aucun code n’est partagé entre elles. Les deux sont des modèles de comportement et, en tant que tels, sont consommés de la même manière par les clients. En règle générale, les stratégies ont une méthode publique unique – la méthode execute() , alors que les modèles peuvent définir un ensemble de méthodes publiques ainsi qu’un ensemble de primitives privées à implémenter par les sous-classes.

Les deux modèles peuvent facilement être utilisés ensemble. Vous pouvez avoir un modèle de stratégie où plusieurs implémentations appartiennent à une famille de stratégies implémentées à l’aide d’un modèle de modèle.

Vous voulez probablement dire modèle de méthode de modèle. Vous avez raison, ils servent des besoins très similaires. Je dirais qu’il est préférable d’utiliser la méthode du modèle dans les cas où vous avez un algorithme “modèle” ayant des étapes définies où les sous-classes remplacent ces étapes pour modifier certains détails. En cas de stratégie, vous devez créer une interface et, au lieu de l’inheritance, vous utilisez la délégation. Je dirais que c’est un modèle un peu plus puissant et peut-être mieux selon les principes d’inversion de dépendance à la norme DIP. Il est plus puissant car vous définissez clairement une nouvelle abstraction de la stratégie – une manière de faire quelque chose qui ne s’applique pas à la méthode des modèles. Donc, si cette abstraction a du sens, utilisez-la. Cependant, l’utilisation de la méthode des modèles peut vous simplifier la conception dans des cas simples, ce qui est également important. Considérez quels mots conviennent le mieux: avez-vous un algorithme de modèle? Ou est la clé ici que vous avez une abstraction de la stratégie – nouvelle façon de faire quelque chose

Exemple de méthode de template:

 Application.main() { Init(); Run(); Done(); } 

Ici, vous héritez de l’application et remplacez ce qui sera fait exactement sur init, run et done.

Exemple de stratégie:

 array.sort (IComparer comparer) 

Ici, lors de l’écriture d’un comparateur, vous n’héritez pas d’un tableau. Array délègue l’algorithme de comparaison à un comparateur

Je pense que les diagrammes de classes des deux modèles montrent les différences.

Stratégie
Encapsule un algorithme dans une classe
Lien vers l’image entrer la description de l'image ici

Méthode du modèle
Reporter les étapes exactes d’un algorithme à une sous-classe
Lien vers l’image entrer la description de l'image ici

Héritage versus agrégation (is-a versus has-a). C’est deux façons d’atteindre le même objective.

Cette question montre certains des compromis entre les choix: inheritance et agrégation

Différence entre stratégie et modèle Méthode de modèle de stratégie vs méthode de modèle


Similitudes

Les modèles de méthode de stratégie et de modèle ont beaucoup de similitudes entre eux. Les modèles de méthode de stratégie et de modèle peuvent être utilisés pour satisfaire le principe ouvert-fermé et rendre le module logiciel facile à étendre sans changer son code. Les deux modèles représentent la séparation des fonctionnalités génériques de l’implémentation détaillée de cette fonctionnalité. Cependant, ils diffèrent un peu en termes de granularité.


Différences

Voici quelques-unes des différences que j’ai observées en étudiant ces deux modèles:

  1. Dans Strategy, le couplage entre le client et la stratégie est plus souple, alors que dans la méthode Template, les deux modules sont plus étroitement couplés.
  2. Dans Strategy, une interface est principalement utilisée, bien que la classe abstraite puisse également être utilisée en fonction de la situation, et que la classe béton ne soit pas utilisée alors que dans la méthode Template, la classe abstraite ou la classe concrète est principalement utilisée, l’interface n’est pas utilisée.
  3. Dans le modèle de stratégie, le comportement entier de la classe est généralement représenté sous la forme d’une interface, par contre, la méthode Template est utilisée pour réduire la duplication de code et le code standard est défini dans le framework de base ou la classe abstraite. Dans la méthode Template, il peut même y avoir une classe concrète avec une implémentation par défaut.
  4. En termes simples, vous pouvez modifier l’intégralité de la stratégie (algorithme) dans le modèle de stratégie, cependant, dans la méthode Template, seules certaines choses changent (parties de l’algorithme) et le rest des choses rest inchangé. Dans Template Method, les étapes invariantes sont implémentées dans une classe de base abstraite, tandis que les étapes variant sont soit une implémentation par défaut, soit aucune implémentation. Dans la méthode Template, le concepteur de composants impose les étapes requirejses d’un algorithme et l’ordre des étapes, mais permet au client du composant d’étendre ou de remplacer un certain nombre de ces étapes.

L’image est tirée du blog bitesized .

Les deux sont très similaires et les deux sont consommés par le code client de manière similaire. Contrairement à ce que dit la réponse la plus populaire ci-dessus, les deux permettent la sélection d’algorithmes au moment de l’exécution .

La différence entre les deux réside dans le fait que si le modèle de stratégie permet à différentes implémentations d’utiliser des méthodes complètement différentes pour obtenir le résultat souhaité, le modèle de méthode de modèle spécifie un algorithme global (la méthode “modèle”) – le seul choix laissé aux implémentations spécifiques (sous-classes) est certains détails de la méthode dite de template. Pour ce faire, la méthode template doit faire appel à une ou plusieurs méthodes abstraites qui sont remplacées (c’est-à-dire mises en œuvre) par les sous-classes, contrairement à la méthode template qui n’est pas abstraite .

Le code client appelle la méthode template en utilisant une référence / un pointeur du type de classe abstrait pointant vers une instance de l’une des sous-classes concrètes, qui peut être déterminée au moment de l’exécution, comme avec le modèle de stratégie.

Méthode de modèle:

  1. C’est basé sur l’ inheritance
  2. Définit le squelette de l’algorithme qui ne peut pas être modifié par les sous-classes. Seules certaines opérations peuvent être remplacées dans les sous-classes
  3. La classe parente contrôle complètement l’algorithme et ne diffère que certaines étapes pour des classes concrètes
  4. La liaison est faite au moment de la compilation

Structure template_method :

entrer la description de l'image ici

Stratégie:

  1. C’est basé sur la délégation / composition
  2. Il modifie les entrailles de l’object en modifiant le comportement de la méthode
  3. Il permet de passer d’une famille d’algorithmes à l’autre
  4. Il modifie le comportement de l’object au moment de l’exécution en remplaçant complètement un algorithme par un autre algorithme à l’exécution
  5. La liaison est effectuée au moment de l’exécution

Structure de la stratégie :

entrer la description de l'image ici

Jetez un coup d’œil à la méthode des modèles et aux articles de stratégie pour une meilleure compréhension.

Articles Similaires:

Modèle de conception de modèle dans JDK, impossible de trouver une méthode définissant un ensemble de méthodes à exécuter dans l’ordre

Real World Exemple de modèle de stratégie

Non, ils ne sont pas nécessairement consommés de la même manière. Le modèle “template method” est un moyen de fournir des “conseils” aux futurs développeurs. Vous leur dites: “Tous les objects Personne doivent avoir un numéro de sécurité sociale” (c’est un exemple sortingvial, mais cela permet de faire passer l’idée correctement).

Le modèle de stratégie permet d’activer et de désactiver plusieurs implémentations possibles. Il n’est pas (généralement) implémenté via l’inheritance, mais plutôt en laissant l’appelant passer l’implémentation souhaitée. Un exemple pourrait être de permettre à un ShippingCalculator de disposer de plusieurs méthodes différentes de calcul des taxes (une implémentation NoSalesTax et une implémentation PercentageBasedSalesTax, par exemple).

Ainsi, parfois, le client indiquera réellement à l’object quelle stratégie utiliser. Un péché

 myShippingCalculator.CalculateTaxes(myCaliforniaSalesTaxImpl); 

Mais le client ne le ferait jamais pour un object basé sur la méthode du modèle. En fait, le client peut même ne pas savoir qu’un object est basé sur une méthode de modèle. Ces méthodes abstraites dans le modèle de méthode de modèle pourraient même être protégées, auquel cas le client ne saurait même pas qu’elles existent.

Je vous suggère de lire cet article. Il explique les différences sur un exemple de cas réel.

Citation de l’article

Comme on peut le voir, les classes d’implémentation dépendent également de la classe de la méthode du template. Cette dépendance amène à changer la méthode du template si l’on veut changer certaines étapes de l’algorithme. De l’autre côté, la stratégie encapsule complètement l’algorithme. classes pour définir complètement un algorithme.Par conséquent, si un changement arrive, il faut changer le code pour les classes précédemment écrites.C’était la principale raison pour laquelle je choisis la stratégie pour concevoir les classes.

Une caractéristique de la méthode de gabarit est que la méthode de gabarit contrôle l’algorithme. Ce qui peut être une bonne chose dans une autre situation, mais dans mon problème, cela me limitait à concevoir les classes. D’un autre côté, la stratégie ne contrôle pas les étapes d’un algorithme qui me permet d’append des méthodes de conversion complètement différentes. Par conséquent, dans mon cas, la stratégie m’aide à mettre en œuvre.

Un inconvénient de la stratégie est qu’il ya trop de redondance de code et moins de partage de code. Comme il est évident dans l’exemple présenté de cet article, je dois répéter le même code dans quatre classes à plusieurs resockets. Il est donc difficile à maintenir car si l’implémentation de notre système tel que l’étape 4, commune à tous, est modifiée, il faudra que je mette à jour cela dans les 5 classes. D’un autre côté, dans la méthode des modèles, je ne peux modifier que la superclasse et les modifications sont reflétées dans les sous-classes. Par conséquent, la méthode des modèles donne une très faible quantité de redondance et une grande quantité de partage de code entre les classes.

La stratégie permet également de modifier l’algorithme au moment de l’exécution. Dans la méthode template, il faudra réinitialiser l’object. Cette caractéristique de la stratégie offre une grande souplesse. Du sharepoint vue de la conception, il faut préférer la composition à l’inheritance. Par conséquent, l’utilisation du modèle de stratégie est également devenue le principal choix pour le développement. “

Le modèle de modèle est similaire au modèle de stratégie. Ces deux modèles diffèrent en termes de scope et de méthodologie.

La stratégie est utilisée pour permettre aux appelants de modifier un algorithme complet, comme la manière de calculer différents types de taxe, tandis que la méthode Template permet de varier les étapes d’un algorithme. De ce fait, la stratégie est plus grossière. Le modèle permet des contrôles plus précis dans la suite des opérations, tout en permettant aux implémentations de ces détails de varier.

La principale différence réside dans le fait que Strategy utilise la délégation alors que la méthode Template utilise l’inheritance. Dans Strategy, l’algorithme est délégué à l’autre classe xxxStrategy à laquelle le sujet aura une référence, mais avec Template, vous sous-classe la base et remplacez les méthodes pour apporter des modifications.

à partir de http://cyruscrypt.blogspot.com/2005/07/template-vs-strategy-patterns.html

Dans les stratégies, les sous-classes exécutent l’émission et contrôlent l’algorithme. Ici, le code est dupliqué dans les sous-classes. La connaissance de l’algorithme et la manière de l’implémenter sont réparties sur plusieurs classes.

Dans le modèle de modèle, la classe de base a un algorithme. Il maximise la réutilisation parmi les sous-classes. Puisque l’algorithme se trouve à un endroit, la classe de base le protège.

Modèle de modèle:

La méthode du modèle consiste à laisser les sous-classes redéfinir certaines étapes de l’algorithme, sans changer la structure principale et les étapes de l’algorithme, définies dans la classe de base. Le modèle de modèle utilise généralement l’inheritance, de sorte qu’une implémentation générique d’algorithmes peut être fournie dans la classe de base, que la sous-classe pourrait choisir de remplacer si nécessaire.

 public abstract class RobotTemplate { /* This method can be overridden by a subclass if required */ public void start() { System.out.println("Starting...."); } /* This method can be overridden by a subclass if required */ public void getParts() { System.out.println("Getting parts...."); } /* This method can be overridden by a subclass if required */ public void assemble() { System.out.println("Assembling...."); } /* This method can be overridden by a subclass if required */ public void test() { System.out.println("Testing...."); } /* This method can be overridden by a subclass if required */ public void stop() { System.out.println("Stopping...."); } /* * Template algorithm method made up of multiple steps, whose structure and * order of steps will not be changed by subclasses. */ public final void go() { start(); getParts(); assemble(); test(); stop(); } } /* Concrete subclass overrides template step methods as required for its use */ public class CookieRobot extends RobotTemplate { private Ssortingng name; public CookieRobot(Ssortingng n) { name = n; } @Override public void getParts() { System.out.println("Getting a flour and sugar...."); } @Override public void assemble() { System.out.println("Baking a cookie...."); } @Override public void test() { System.out.println("Crunching a cookie...."); } public Ssortingng getName() { return name; } } 

Notez que dans le code ci-dessus, les étapes de l’algorithme go () seront toujours les mêmes, mais les sous-classes pourraient définir une recette différente pour effectuer une étape particulière.

Modèle de stratégie:

Le modèle de stratégie consiste à laisser le client sélectionner l’implémentation d’algorithmes concrets à l’exécution. Tous les algorithmes sont isolés et indépendants, mais implémentent une interface commune, et il n’y a aucune notion de définition d’étapes particulières dans l’algorithme.

 /** * This Strategy interface is implemented by all concrete objects representing an * algorithm(strategy), which lets us define a family of algorithms. */ public interface Logging { void write(Ssortingng message); } /** * Concrete strategy class representing a particular algorithm. */ public class ConsoleLogging implements Logging { @Override public void write(Ssortingng message) { System.out.println(message); } } /** * Concrete strategy class representing a particular algorithm. */ public class FileLogging implements Logging { private final File toWrite; public FileLogging(final File toWrite) { this.toWrite = toWrite; } @Override public void write(Ssortingng message) { try { final FileWriter fos = new FileWriter(toWrite); fos.write(message); fos.close(); } catch (IOException e) { System.out.println(e); } } } 

Pour le code source complet, consultez mon repository github.

Modèle de conception de stratégie

  • Soutient la composition.
  • Vous offre la possibilité de modifier le comportement de l’object à l’exécution.
  • Moins de couplage entre le code client et le code solution / algorithme.

Modèle de conception de méthode de modèle

  • Favorise l’inheritance par rapport à la composition
  • Définir un algorithme dans votre classe de base. Des éléments individuels d’algorithme peuvent être personnalisés dans des classes enfants.

La stratégie est exposée en tant que méthode d’interface et de modèle comme classe abstraite. Ceci est généralement utilisé dans les frameworks. Par exemple, la classe MessageSource de Spring framework est une interface de stratégie pour la résolution des messages. Le client utilise une implémentation (stratégie) particulière de cette interface.

Et l’implémentation abstraite de la même interface AbstractMessageSource, qui a une implémentation commune de la résolution des messages et expose la méthode abstraite resolveCode () afin que les sous-classes puissent les implémenter dans leurs manières. AbstractMessageSource est un exemple de méthode de template.

http://docs.spring.io/spring/docs/4.1.7.RELEASE/javadoc-api/org/springframework/context/support/AbstractMessageSource.html

Dans la méthode de gabarit de ce modèle de conception, une ou plusieurs étapes d’algorithme peuvent être remplacées par des sous-classes pour permettre des comportements différents tout en garantissant que l’algorithme global est toujours suivi (Wiki).

Le nom du modèle La méthode Template signifie ce qu’il est. Disons que nous avons une méthode CalculateSomething () et que nous voulons modéliser cette méthode. Cette méthode sera déclarée dans la classe de base comme une méthode non virtuelle. Disons que la méthode ressemble à ceci.

 CalculateSomething(){ int i = 0; i = Step1(i); i++; if (i> 10) i = 5; i = Step2(i); return i; 

} L’implémentation de la méthode Step1 et Step2 peut être donnée par des classes dérivées.

Dans Strategy Pattern, il n’y a pas d’implémentation fournie par la base (c’est la raison pour laquelle la base est vraiment une interface dans le diagramme de classes)

L’exemple classique est le sorting. En fonction du nombre d’objects à sortinger, la classe d’algorithme appropriée (fusion, bulle, rapide, etc.) est créée et l’algorithme entier est encapsulé dans chaque classe.

Maintenant, pouvons-nous implémenter le sorting comme méthode de modèle? Certainement, vous le pouvez, mais vous ne trouverez pas beaucoup de points communs ni de points communs à mettre en œuvre dans l’implémentation de base. Donc, cela va à l’encontre de l’objective du modèle de méthode de modèle.