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

https://stackoverflow.com/questions/669271

21-08-2019
|

Question

Quelqu'un peut-il s'il vous plaît me expliquer quelle est la différence entre le modèle de la méthode du modèle et le modèle de stratégie est?

Pour autant que je peux dire qu'ils sont les mêmes 99% - la seule différence que le modèle de procédé de modèle a une classe abstraite en tant que base classe alors que la classe de stratégie utilise une interface qui est mis en œuvre par chaque classe de stratégie concrète.

Cependant, jusqu'à la client concernées, elles sont consommées exactement de la même manière - est-ce correct

La solution

La différence principale entre les deux est lorsque l'algorithme de béton est choisi.

modèle de méthode de modèle cela arrive à la compilation par subclassing le modèle. Chaque sous-classe fournit un autre algorithme concret en mettant en œuvre des méthodes abstraites du modèle. Lorsqu'un client invoque les méthodes de l'interface externe du modèle le modèle appelle ses méthodes abstraites (son interface interne) au besoin d'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 motif de stratégie permet à un algorithme au choix à exécution en confinement . Les algorithmes concrets sont mis en œuvre par des classes séparées ou des fonctions qui sont passés à la stratégie en tant que paramètre à son constructeur ou à une méthode setter. Quel algorithme est choisi pour ce paramètre peut varier dynamiquement 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é:

motif de modèle de procédé: compilation sélection de l'algorithme par subclassing
motif de stratégie: algorithme d'exécution sélection par confinement

Autres conseils

Le schéma de modèle est utilisée lors d'une opération particulière a un comportement invariant (s) qui peut être définie en fonction d'autres variables comportements primitifs. La classe abstraite définit le comportement invariant (s), tandis que les classes d'application défini les méthodes dépendantes.

Dans une stratégie, les implémentations de comportement sont indépendants - chaque classe d'application définit le comportement et il n'y a pas de code partagé entre eux. Les deux sont des modèles de comportement et, en tant que tels, sont consommés de la même façon par les clients. Typiquement stratégies ont une seule méthode publique - la méthode execute(), alors que les modèles peuvent définir un ensemble de méthodes publiques ainsi qu'un ensemble de soutien primitives privées qui doivent mettre en œuvre des sous-classes

Les deux modèles pourraient facilement être utilisés ensemble. Vous pourriez avoir un modèle de stratégie où plusieurs implémentations appartiennent à une famille de stratégies mises en œuvre en utilisant un modèle de modèle.

Je pense que la classe des deux diagrammes modèle sont montrant les différences.

Stratégie Encapsule un algorithme dans une classe

Méthode modèle Différer les étapes exactes d'un algorithme à une sous-classe

Vous voulez dire probablement modèle de la méthode 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 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 changer quelques détails. Dans le cas de la stratégie, vous devez créer une interface, et au lieu de l'héritage que vous utilisez délégation. Je dirais qu'il est un peu plus puissant modèle et peut-être mieux en accord avec DIP - dépendance principes d'inversion. Il est plus puissant que vous définissez clairement une nouvelle abstraction de la stratégie - une façon de faire quelque chose qui ne s'applique pas à la méthode de modèle. Donc, si cette abstraction est logique - l'utiliser. Cependant, en utilisant la méthode de modèle peut vous donner une conception plus simple dans les cas simples, ce qui est également important. Considérez que les mots correspondent mieux: avez-vous un algorithme de modèle? Ou est l'élément clé ici est que vous avez une abstraction de la stratégie - nouvelle façon de faire quelque chose

Exemple d'un procédé de template:

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

Vous héritez de l'application et remplacer exactement ce qui sera fait sur init, courir et faire.

Exemple d'une stratégie:

array.sort (IComparer<T> comparer)

Ici, lors de l'écriture d'un comparateur, vous ne héritons pas d'un tableau. les délégués Array, l'algorithme de comparaison à un comparateur.

Similitudes

modèles méthode stratégie et du modèle ont beaucoup de similitudes entre eux. Les deux modèles de la méthode et la stratégie de modèles peuvent être utilisés pour satisfaire le principe ouvert-fermé et rendant 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 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 quelques-unes des différences que je l'ai observé pendant l'étude de ces deux motifs:

Dans la stratégie, le couplage entre le client et la stratégie est plus lâche tandis que dans la méthode de modèle, les deux modules sont plus étroitement couplé.
Dans la stratégie, la plupart du temps une interface est utilisée si classe abstraite peut également être utilisé en fonction de la situation et classe concrète n'est pas utilisé alors que dans la méthode de modèle classe la plupart du temps abstrait ou concret classe est utilisée, l'interface n'est pas utilisé.
Dans la stratégie modèle, le comportement généralement ensemble de la classe est représenté en termes d'une interface, d'autre part, la méthode est utilisée Template pour réduire le chevauchement et le code de passe-partout est défini dans le code cadre de base ou classe abstraite. Dans Modèle de méthode, il peut même être une classe concrète la mise en œuvre par défaut.
En mots simples, vous pouvez modifier l'ensemble de la stratégie (algorithme) dans motif de stratégie, cependant, dans la méthode de modèle, que certaines choses changement (parties de l'algorithme) et reste des choses restent inchangées. Dans Template Method, les étapes invariantes sont mises en œuvre dans une classe de base abstraite, tandis que le étapes variantes sont donnés soit une implémentation par défaut, ou pas la mise en œuvre du tout. Dans la méthode du modèle, le concepteur de composants mandate les étapes nécessaires d'un algorithme, et l'ordre des étapes, mais permet d'étendre le composant client ou remplacer certaines nombre de ces étapes.

L'image est tirée de la bitesized blog.

Inheritance par rapport à l'agrégation (est-un par rapport a-a). Il 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 semblables, et les deux sont consommés par le code client de la même façon. Contrairement à ce que la réponse la plus populaire dit ci-dessus, les deux permettent la sélection de l'algorithme lors de l'exécution .

La différence entre les deux est que si le modèle de stratégie permet différentes implémentations d'utiliser de manière complètement différente de la réalisation des résultats escomptés, le modèle de méthode modèle spécifie un global algorithme (la méthode « template ») qui est utilisé pour obtenir le résultat - le seul choix laissé aux implémentations spécifiques (sous-classes) sont certains détails de cette méthode de modèle. Cela se fait en ayant la la méthode de modèle font appel (s) à un ou plusieurs abstrait méthodes qui sont surchargées (par exemple mis en œuvre) par les sous-classes, contrairement à la méthode du modèle qui lui-même est pas abstraite et pas contredite par les sous-classes.

Le code client fait un appel à la méthode de modèle à l'aide d'une référence / pointeur du type de classe abstraite pointant vers une instance de l'une des classes de béton sous qui peut être déterminé au moment de l'exécution comme en utilisant le modèle de stratégie.

Modèle Méthode:

Il est basé sur héritage
définit le squelette de l'algorithme qui ne peut pas être changé par des sous classes. Seules certaines opérations peuvent être remplacées dans les classes sous
classe parent complètement contrôle l'algorithme et ne diffère que certaines étapes à des classes concrètes
La liaison est effectuée au moment de la compilation

Template_method la structure:

Stratégie:

Il est basé sur délégation / composition
Il change les tripes de l'objet en modifiant le comportement de la méthode
Il est utilisé pour commutateur entre la famille d'algorithmes
Il modifie le comportement de l'objet au moment de l'exécution par complètement le remplacement d'un algorithme avec un autre algorithme lors de l'exécution
La liaison permet à l'exécution

structure de stratégie:

Jetez un oeil à méthode de modèle Stratégie d'articles pour une meilleure compréhension de.

modèle de conception de modèle dans JDK, n'a pas pu trouver une méthode définissant ensemble de méthodes à exécuter dans l'ordre

Exemple réel du modèle Stratégie

Non, ils ne sont pas nécessairement consommés de la même manière. Le modèle « méthode template » est un moyen de fournir « des conseils » pour les futurs exécutants. Vous leur dites: « Tous les objets personne doit avoir un numéro de sécurité sociale » (c'est un exemple trivial, mais il a l'idée à travers correctement).

Le modèle de stratégie permet plusieurs possibles mises en œuvre à commuter et sortir. Il n'est pas (en général) mis en œuvre par héritage, mais en laissant l'appelant passer dans la mise en œuvre souhaitée. Un exemple pourrait être un permettant ShippingCalculator à fournir à l'une de plusieurs façons différentes de calcul des taxes (une mise en œuvre NoSalesTax, et une mise en œuvre PercentageBasedSalesTax peut-être).

Alors, parfois, le client fait dire l'objet stratégie à utiliser. Comme dans

myShippingCalculator.CalculateTaxes(myCaliforniaSalesTaxImpl);

Mais le client ne ferait jamais que pour un objet qui a été basé sur la méthode modèle. En fait, le client peut même pas savoir un objet est basé sur la méthode modèle. Ces méthodes abstraites dans le modèle Méthode modèle pourraient même être protégés, dans ce cas, le client ne sait même pas qu'ils existent.

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

Citation de l'article

" Comme on peut le voir la mise en œuvre des classes dépend aussi du modèle   classe de méthode. Cette dépendance fait changer la méthode de modèle si   on veut changer quelques-unes des étapes de l'algorithme. De l'autre   stratégie de côté encapsule complètement l'algorithme. il donne la   la mise en œuvre des classes pour définir complètement un algorithme. Par conséquent, si   tout changement arrive un n'a pas besoin de changer le code précédemment   les classes écrites. Ce fut la principale raison je choisis stratégie   concevoir les classes.

Une caractéristique de la méthode du modèle est que la méthode de modèle contrôle la   algorithme. Ce qui peut être une bonne chose dans une autre situation, mais dans mon   problème ce me bornant à concevoir les classes. De l'autre   stratégie latérale ne contrôle pas les étapes d'un algorithme qui permet   moi d'ajouter complètement différentes méthodes de conversion. Par conséquent, dans mon cas   stratégie me aide pour la mise en œuvre.

Un inconvénient de la stratégie est qu'il ya trop de redondance de code et   moins le partage de code. Comme il est évident dans l'exemple présenté de cette   article, je dois répéter le même code dans quatre classes à nouveau et   encore. Il est donc difficile de maintenir parce que si la mise en œuvre   de notre système tel que l'étape 4 qui est commune à tous est changé alors je   devra mettre à jour ce dans les 5 classes. De l'autre côté, en   méthode modèle, je ne peux changer la superclasse et les changements sont   reflété dans les sous-classes. Par conséquent, la méthode de modèle donne une très   faible quantité de redondance et haute quantité de partage de code entre les   classes.

La stratégie permet également de changer l'algorithme lors de l'exécution. en modèle   on aura procédé à ré-initialiser l'objet. Cette caractéristique de   stratégie fournir grande flexibilité. Du point de conception   vue que l'on a à la composition préférerons l'héritage. Par conséquent, l'utilisation   modèle de stratégie est également devenu le premier 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 dans la portée et la méthodologie.

La stratégie est utilisée pour permettre aux appelants de faire varier un algorithme entier, comme la façon de calculer les différents types d'impôts, alors que la méthode modèle permet de faire varier les étapes d'un algorithme. Pour cette raison, la stratégie est plus grossièrement grain. Le modèle permet des contrôles plus fins grains dans le séquent des opérations, et permet encore les mises en œuvre de ces détails peuvent varier.

L'autre principale différence est que la stratégie utilise la délégation alors que modèle Méthode utilise l'héritage. Dans la stratégie, l'algorithme est déléguée à une autre classe xxxStrategy que le sujet aura une référence, mais avec modèle vous sous-classe la base et passer outre des méthodes pour apporter des modifications.

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

Dans les sous-classes de motif stratégie sont en cours d'exécution le spectacle et ils contrôlent l'algorithme. Ici, le code est dupliqué à travers les sous-classes. La connaissance de l'algorithme et la façon de la mettre en œuvre est répartie sur de nombreuses classes.

En forme de modèle, classe de base a algorithme. Il maximise la réutilisation parmi les sous-classes. Étant donné que l'algorithme est en un seul endroit, classe de base protège.

Design Pattern Stratégie

Supports composition.
vous offre la possibilité de modifier le comportement de l'objet lors de l'exécution.
Moins couplage entre le code client et la solution / code d'algorithme.

Méthode Modèle Design Pattern

Favors héritage sur la composition
Définir l'algorithme dans votre classe de base. Des pièces individuelles de l'algorithme peuvent être personnalisés dans les classes d'enfants.

Modèle de modèle:

Procédé de modèle est de laisser certaines sous-classes redéfinissent étapes de l'algorithme, sans modifier la structure principale et les étapes de l'algorithme, défini dans la classe de base. modèle de modèle utilise généralement l'héritage, donc une implémentation générique d'algorithmes peuvent être fournis dans la classe de base, 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;
    }
}

Note dans le code ci-dessus, les étapes de l'algorithme go () sera toujours le même, mais les sous-classes peut définir une recette différente pour effectuer une étape particulière.

Modèle de stratégie:

modèle de stratégie est de laisser le client sélectionne la mise en œuvre des algorithmes concrets lors de l'exécution. Tous les algorithmes sont isolés et indépendants, mais la mise en œuvre d'une interface commune, et il n'y a aucune notion de définition des étapes particulières au sein de 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 .

La stratégie est exposée comme une méthode d'interface et modèle comme la classe abstraite. Ceci est généralement utilisé beaucoup dans les cadres. par exemple. classe de framework Spring MessageSource est une interface de stratégie pour résoudre les messages. Le client utilise la mise en œuvre particulière (stratégie) de cette interface.

Et la mise en œuvre abstraite de la même AbstractMessageSource d'interface, qui a la mise en œuvre commune des messages et expose la résolution méthode abstraite resolveCode () de sorte que les sous-classes peuvent les mettre en œuvre dans leurs moyens. AbstractMessageSource est un exemple de procédé de modèle.

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

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 pour permettre différents comportements tout en assurant que l'algorithme global est toujours suivi (Wiki).

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

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

} la mise en œuvre de la méthode et l'étape 1 Etape 2 peut être donné par les classes dérivées.

Dans Motif, il n'est la stratégie mise en œuvre fournie par la base (Ceci 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 doit être triée la classe algorithme approprié (fusion, bulles, etc. rapide) est créé et l'ensemble de l'algorithme est encapsulé dans chaque classe.

Maintenant, nous pouvons mettre en œuvre le tri comme méthode de modèle? Certes, vous pouvez, mais vous ne trouverez pas beaucoup / des points communs à abstraire et placés dans la mise en œuvre de base. Donc, il va à l'encontre du but de modèle de méthode de modèle.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow