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 s'il vous plaît quelle est la différence entre le modèle de méthode de modèle et le modèle de stratégie?
Autant que je sache, ils sont à 99% identiques. La seule différence est que le modèle de méthode de modèle a une classe abstraite comme classe de base, tandis que la classe de stratégie utilise une interface implémentée par chaque classe de stratégie concrète.
Cependant, en ce qui concerne 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 Modèle de méthode, cela se produit à au moment de la compilation par sous-classement 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) nécessaires à l'appel de 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 à l'exécution par confinement . Les algorithmes concrets sont implémentés par des classes ou des fonctions séparées qui sont transmises à la stratégie en tant que paramètre à son constructeur ou à une méthode de définition. L'algorithme choisi pour ce paramètre peut varier dynamiquement en fonction de l'état du programme ou des entrées.
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: à la compilation sélection de l'algorithme par sous-classement
- Modèle de stratégie: algorithme d'exécution sélection par confinement
Le modèle de modèle est utilisé lorsqu'une opération particulière a un ou plusieurs comportements invariants qui peuvent être définis en termes d'autres comportements primitifs variables. 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 il n'y a pas de code 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. Les stratégies ont généralement une seule méthode publique - la méthode execute(), tandis que les modèles peuvent définir un ensemble de méthodes publiques ainsi qu'un ensemble de primitives privées de prise en charge que les sous-classes doivent implémenter.
Les deux modèles pourraient facilement être utilisés ensemble. Vous pouvez avoir un modèle de stratégie où plusieurs implémentations appartiennent à une famille de stratégies mises en œuvre à l'aide d'un modèle de modèle.
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 
Méthode du modèle
Reporter les étapes exactes d'un algorithme à une sous-classe
Lien vers l'image 
Vous voulez probablement dire modèle de méthode de modèle. Vous avez raison, ils répondent à des besoins très similaires. Je dirais qu'il est préférable d'utiliser la méthode template dans les cas où vous avez un algorithme "template" 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 d'un héritage, vous utilisez la délégation. Je dirais que c'est un modèle un peu plus puissant et peut-être mieux conforme aux principes d'inversion de dépendance DIP. C'est plus puissant parce que vous définissez clairement une nouvelle abstraction de stratégie - une façon de faire quelque chose, qui ne s'applique pas à la méthode du modèle. Donc, si cette abstraction a un sens, utilisez-la. Cependant, l'utilisation de la méthode des modèles peut vous donner des conceptions plus simples dans des cas simples, ce qui est également important. Déterminez quels mots conviennent le mieux: avez-vous un algorithme de modèle? Ou bien l’essentiel ici est-il 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 substituez ce qui sera exactement fait sur init, run et done.
Exemple de stratégie:
array.sort (IComparer<T> 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.
Similitudes
Les modèles de méthodes Stratégie et Modèle ont beaucoup de similitudes entre eux. Les modèles de méthode Stratégie et 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 une séparation entre la fonctionnalité générique et la mise en œuvre détaillée de cette fonctionnalité. Cependant, ils diffèrent un peu en termes de granularité qu'ils offrent.
Différences
Voici certaines des différences que j'ai observées lors de l'étude de ces deux modèles:
- En stratégie, le couplage entre le client et la stratégie est plus souple, tandis que dans la méthode des modèles, les deux modules sont plus étroitement couplés.
- Dans Strategy, la plupart du temps, une interface est utilisée, bien que la classe abstraite puisse également être utilisée en fonction de la situation. Aucune classe concrète n’est utilisée alors que dans la méthode Template, on utilise principalement une classe abstraite ou une classe concrète. Aucune interface n’est utilisée.
- Dans le modèle Stratégie, l’ensemble du comportement de la classe est généralement représenté en termes d’interface. Par ailleurs, la méthode Template est utilisée pour réduire la duplication de code et le code standard est défini dans le cadre de base ou la classe abstraite. Dans la méthode Template, il peut même exister une classe concrète avec une implémentation par défaut.
- En termes simples, vous pouvez modifier l’ensemble de la stratégie (algorithme) dans Modèle de stratégie. Toutefois, dans la méthode Modèle, seules certaines modifications (parties de l’algorithme) sont modifiées et le reste des opérations reste inchangé. Dans la méthode du modèle, les étapes invariantes sont implémentées dans une classe de base abstraite, tandis que les étapes variantes reçoivent une implémentation par défaut ou aucune implémentation. Dans la méthode Template, le concepteur de composants impose les étapes requises d'un algorithme et l'ordre de ces étapes, mais permet au composant client d'étendre ou de remplacer un certain nombre de ces étapes.
L'image est tirée du blog bitesized .
Héritage versus agrégation (is-a versus has-a). C'est deux façons d'atteindre le même objectif.
Cette question montre certains des compromis entre les choix: héritage vs agrégation
Les deux sont très similaires et sont tous deux consommés de la même manière par le code client. Contrairement à ce que dit la réponse la plus populaire ci-dessus, les deux permettent la sélection d'un algorithme 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 atteindre le résultat souhaité, le modèle modèle de méthode modèle spécifie un algorithme global (la méthode "modèle") à utiliser pour obtenir le résultat - le seul choix qui reste aux implémentations spécifiques (sous-classes) sont certains détails de ladite méthode de modèle. Ceci est fait en faisant en sorte que la méthode template passe un appel à une ou plusieurs méthodes abstraites qui sont surchargées (c'est-à-dire implémentées) par les sous-classes. , contrairement à la méthode template qui elle-même n’est pas abstraite et non surchargée par les sous-classes.
Le code client appelle la méthode template à l'aide d'une référence/d'un pointeur du type de classe abstraite pointant vers une instance de l'une des sous-classes concrètes pouvant être déterminées au moment de l'exécution, comme lors de l'utilisation du modèle de stratégie.
Méthode du modèle:
- Il est basé sur l'héritage
- Définit le squelette de l'algorithme qui ne peut pas être modifié par les sous-classes. Seules certaines opérations peuvent être écrasées dans les sous-classes
- La classe parente contrôle complètement l'algorithme et ne diffère que de certaines étapes en classes concrètes
- La liaison est faite à la compilation
Template_method structure:
Stratégie:
- Il est basé sur délégation/composition
- Il change les entrailles de l'objet en modifiant le comportement de la méthode
- Il est utilisé pour passer d'une famille d'algorithmes à l'autre
- Il modifie le comportement de l'objet au moment de l'exécution en remplaçant complètement un algorithme par un autre lors de l'exécution
- La liaison est faite au moment de l'exécution
Stratégie structure:
Consultez les articles méthode du modèle et Stratégie pour une meilleure compréhension.
Articles Similaires:
Non, ils ne sont pas nécessairement consommés de la même manière. Le modèle "méthode modèle" est un moyen de fournir des "conseils" aux futurs développeurs. Vous leur dites: "Tous les objets Personne doivent avoir un numéro de sécurité sociale" (c'est un exemple trivial, mais l'idée est correctement transmise).
Le modèle de stratégie permet de multiples implémentations possibles. Il n'est pas (généralement) mis en œuvre par héritage, mais en laissant l'appelant passer dans l'implémentation souhaitée. Un exemple pourrait être de permettre à ShippingCalculator de disposer de l’une des différentes méthodes de calcul des taxes (une implémentation NoSalesTax, et peut-être une implémentation PourcentageBasedSalesTax).
Ainsi, parfois, le client indiquera à l'objet quelle stratégie utiliser. Un péché
myShippingCalculator.CalculateTaxes(myCaliforniaSalesTaxImpl);
Mais le client ne ferait jamais cela pour un objet basé sur la méthode Template. En fait, le client peut même ne pas savoir qu'un objet est basé sur la méthode du modèle. Ces méthodes abstraites dans le modèle Template Method 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 this article. Il explique les différences sur un exemple de cas réel.
Extrait de l'article
" Comme on peut le voir, les classes d'implémentation dépendent également de la classe de la méthode template. Cette dépendance entraîne le changement de la méthode template si l'on souhaite modifier certaines étapes de l'algorithme. De l'autre côté, la stratégie encapsule complètement l'algorithme. il donne aux classes implémentées la possibilité de définir complètement un algorithme. Par conséquent, si un changement survient, il est nécessaire de changer le code des classes écrites précédemment. C’est la raison principale pour laquelle j’ai choisi une stratégie pour concevoir les classes.
L'une des caractéristiques de la méthode template est que cette méthode contrôle l'algorithme. Ce qui peut être une bonne chose dans d'autres situations, mais dans mon problème, cela me limitait à la conception des classes. De l'autre côté, la stratégie ne contrôle pas les étapes d'un algorithme qui me permet d'ajouter des méthodes de conversion complètement différentes. Par conséquent, dans mon cas, la stratégie m’aide à la mise en œuvre.
Un des inconvénients de la stratégie est qu’il existe 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, encore et encore. Il est donc difficile à maintenir car si l’implémentation de notre système telle que l’étape 4, qui est commune à tous, est modifiée, il me faudra alors mettre à jour cette information dans les 5 classes. De l’autre côté, avec la méthode template, je ne peux que changer la super-classe et les modifications sont reflétées dans les sous-classes. Par conséquent, la méthode de modèle donne une très faible quantité de redondance et un grand nombre de partage de code entre les classes.
La stratégie permet également de changer l'algorithme au moment de l'exécution. Dans la méthode template, il faudra réinitialiser l'objet. Cette caractéristique de stratégie offre une grande flexibilité. Du point de vue de la conception, il faut préférer la composition à l’héritage. Par conséquent, utiliser un modèle de stratégie est également devenu le premier choix de développement. "
Le modèle de modèle est similaire au modèle de stratégie. Ces deux modèles diffèrent par la portée et la méthodologie.
La stratégie est utilisée pour permettre aux appelants de modifier un algorithme entier, par exemple, comment calculer différents types de taxe, tandis que la méthode du modèle est utilisée pour modifier les étapes d'un algorithme. De ce fait, la stratégie est plus grossièrement grainée. Le modèle permet des contrôles plus détaillés dans la suite des opérations, tout en permettant aux implémentations de ces détails de varier.
L'autre principale différence est que Strategy utilise la délégation alors que la méthode Template utilise l'héritage. 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-classez la base et les méthodes de remplacement pour effectuer les modifications.
de http://cyruscrypt.blogspot.com/2005/07/template-vs-strategy-patterns.html
Dans le modèle de stratégie, les sous-classes exécutent le spectacle et contrôlent l'algorithme. Ici, le code est dupliqué dans les sous-classes. La connaissance de l'algorithme et son implémentation sont répartis sur de nombreuses classes.
Dans le modèle de modèle, la classe de base a un algorithme. Il maximise la réutilisation parmi les sous-classes. Comme l’algorithme est situé au même endroit, la classe de base le protège.
Modèle de conception de stratégie
- Soutient la composition.
- Vous offre la possibilité de changer le comportement d'un objet lors de l'exécution.
- Moins de couplage entre le code client et le code solution/algorithme.
Modèle Méthode Design Pattern
- Favorise l'héritage par rapport à la composition
- Définissez l'algorithme dans votre classe de base. Des éléments individuels de l'algorithme peuvent être personnalisés dans les classes enfants.
Modèle de modèle:
La méthode des modèles consiste à laisser les sous-classes redéfinir certaines étapes de l'algorithme, sans modifier 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'héritage, de sorte qu'une implémentation générique d'algorithmes peut être fournie dans la classe de base, que la sous-classe peut 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 String name;
public CookieRobot(String 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 String 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 peuvent définir une recette différente pour l'exécution d'une étape particulière.
Modèle de stratégie:
Le modèle de stratégie consiste à laisser le client choisir l'implémentation d'algorithmes concrets lors de l'exécution. Tous les algorithmes sont isolés et indépendants, mais implémentent une interface commune et il n’existe 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(String message);
}
/**
* Concrete strategy class representing a particular algorithm.
*/
public class ConsoleLogging implements Logging {
@Override
public void write(String 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(String 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 github référentiel .
Dans la méthode de modèle de ce modèle de conception, une ou plusieurs étapes de l'algorithme peuvent être remplacées par des sous-classes afin de permettre des comportements différents tout en garantissant que l'algorithme global est toujours suivi (Wiki).
La méthode de modèle de nom de modèle signifie ce que c'est. Disons que nous avons une méthode CalculateSomething () et que nous souhaitons modéliser cette méthode. Cette méthode sera déclarée dans la classe de base une méthode non virtuelle. Dites 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 des méthodes Step1 et Step2 peut être donnée par des classes dérivées.
Dans Strategy Pattern, la base ne fournit aucune implémentation (c'est la raison pour laquelle la base est vraiment une interface dans le diagramme de classes).
L'exemple classique est le tri. En fonction du nombre d'objets devant être triés, la classe d'algorithme appropriée (fusion, bulle, rapide, etc.) est créée et l'ensemble de l'algorithme est encapsulé dans chaque classe.
Maintenant, pouvons-nous implémenter le tri en tant que méthode de modèle? Certes, vous pouvez le faire, mais vous ne trouverez pas beaucoup/aucun point commun à extraire et à placer dans l’implémentation de base. Donc, cela va à l'encontre de l'objectif du modèle de méthode template.
La stratégie est exposée en tant que méthode d'interface et de modèle en tant que classe abstraite. Ceci est généralement beaucoup utilisé dans les frameworks. par exemple. La classe MessageSource de la structure Spring est une interface de stratégie permettant de résoudre les messages. Le client utilise une mise en œuvre particulière (stratégie) de cette interface.
Et l'implémentation abstraite de la même interface AbstractMessageSource, qui a une implémentation commune de résolution des messages et expose la méthode abstraite resolCode () afin que les sous-classes puissent les implémenter à leur manière. AbstractMessageSource est un exemple de méthode template.