le modèle de modèle est utilisé lorsqu'une opération particulière a un ou des comportements invariants qui peuvent être définis en termes d'autres comportements primitifs variables. La classe abstraite définit le(s) comportement (s) invariant (s), tandis que les classes d'implémentation définissaient 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, comme tels, sont consommés de la même manière par les clients. En général, les 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 primitives privées de soutien que les sous-classes doivent mettre en œuvre.

les deux motifs 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 mises en œuvre en utilisant un modèle de modèle.

vous voulez probablement dire modèle de méthode de modèle. Vous avez raison, ils servent très similaire besoins. Je dirais qu'il est préférable d'utiliser la méthode de modèle dans les cas où vous avez un algorithme de "modèle" ayant des étapes définies où les sous-classes supplantent ces étapes pour changer certains détails. En cas de stratégie, vous devez créer une interface, et au lieu de l'héritage vous utilisez la délégation. Je dirais que c'est un modèle un peu plus puissant et peut-être mieux en accord avec l'inversion de dépendance principe. Il est plus puissant parce que 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 du modèle. Donc, si cette abstraction a du sens - utilisez-la. Cependant, l'utilisation de la méthode de modèle peut vous donner des conceptions plus simples dans des cas simples, ce qui est également important. Pensez à quels mots correspondent le mieux: avez-vous un algorithme de modèle? Ou est la chose que vous avez ici une abstraction de la stratégie - nouvelle manière de faire quelque chose

Exemple d'un modèle de méthode:

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

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

exemple de stratégie:

array.sort (IComparer<T> comparer)

ici, quand vous écrivez un compareur, vous n'héritez pas d'un tableau. Le tableau délègue l'algorithme de comparaison à un compareur.

je pense que les diagrammes de classe des deux modèles montrent les différences.

stratégie

Encapsule un algorithme à l'intérieur d'une classe

lien vers l'image

Modèle De Méthode

Reporter les étapes exactes d'un algorithme à une sous-classe

Lien vers l'Image

l'Héritage rapport à l'agrégation (est-un rapport a-a). Il est deux façons d'atteindre le même objectif.

cette question montre certains compromis entre les choix: héritage vs. agrégation

similitudes

stratégie et les modèles de méthodes ont beaucoup de similitudes entre eux. Les modèles de stratégie et de méthode de modèle peuvent être utilisés pour satisfaire le principe ouvert-fermé et rendre le module de logiciel facile à étendre sans changer son code. Les deux modèles représentent la séparation de fonctionnalité générique de l'détaillée la mise en œuvre 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 j'ai observées en étudiant ces deux modèles:

1. en stratégie, le couplage entre le client et la stratégie est plus tandis que dans la méthode de gabarit, les deux modules sont plus serrés couplé.
2. In Stratégie, surtout une interface est utilisée si la classe abstraite peut aussi être utilisé en fonction de la situation, et la classe de béton n'est pas utilisé alors que dans la méthode de gabarit principalement la classe abstraite ou le béton la classe est utilisé, l'interface n'est pas utilisé.
3. dans le modèle de stratégie, généralement tout le comportement de la classe est représenté en termes d'interface, d'autre part, la méthode de modèle est utilisée pour réduire la duplication de code et le code boilerplate est défini dans cadre de base ou la classe abstraite. Dans la méthode de gabarit, il peut même y avoir une classe de béton avec implémentation par défaut.
4. en termes simples, vous pouvez changer la stratégie entière (algorithme) en Modèle de stratégie, cependant, dans la méthode de Modèle, seulement certaines choses changement (parties de l'algorithme) et le reste des choses restent inchangées. Dans la méthode de Template, les étapes invariantes sont implémentées dans une classe de base abstraite, tandis que la les étapes de variante sont soit donné une implémentation par défaut, ou aucun application à tous. Dans la méthode de Template, le concepteur de composants mandate les étapes requises d'un algorithme, et l'ordre de pas, mais permet au client de prolonger ou de remplacer certains nombre de ces étapes.

Image tirée du blog bitesized .

les deux sont très semblables et sont consommées par le code client de façon similaire. Contrairement à ce que dit la réponse la plus populaire ci-dessus, les deux permettent la sélection d'algorithme à l'exécution .

la différence entre les deux est que tandis que le schéma de stratégie permet à différentes implémentations d'utiliser des façons complètement différentes de l'atteinte du résultat souhaité, le modèle de méthode de méthode spécifie un algorithme global (la méthode du "modèle") qui est utilisé pour atteindre le résultat -- le seul choix laissé aux implémentations spécifiques (sous-classes) sont certains détails de ladite méthode du modèle. Ceci est fait en demandant à la méthode template de faire appel à une ou plusieurs méthodes abstract qui sont supplantées (i.e. implémentées) par les sous-classes, contrairement à la méthode template qui elle-même n'est pas abstraite et n'est pas supplantée par les sous-classes.

le code client lance un appel à la méthode template en utilisant une référence/pointeur du type de classe abstraite pointant vers une instance d'une des sous-classes concrètes qui peut être déterminée au moment de l'exécution tout comme en utilisant le Pattern de stratégie.

Modèle De La Méthode:

1. il est basé sur héritage
2. définit un squelette d'algorithme qui ne peut pas être modifié par des sous-classes. Seules certaines opérations peuvent être annulées dans les sous-classes
3. classe mère complètement contrôle l'algorithme et ne diffère que de certaines étapes des classes concrètes
La reliure
4. se fait à moment de la compilation

Template_method structure:

stratégie:

1. Il est basé sur la délégation de la composition
2. il change les viscères de l'objet en modifiant le comportement de la méthode
3. Il est utilisé pour basculer entre famille d'algorithmes
4. il modifie complètement le comportement de l'objet au temps d'exécution remplaçant un algorithme par un autre algorithme au temps d'exécution
5. la Liaison se fait au moment de l'exécution

stratégie structure:

regarder Modèle de méthode et Stratégie articles pour mieux comprendre.

articles connexes:

Modèle de modèle de conception dans le JDK, ne pouvait pas trouver une méthode de définition d'un ensemble de méthodes qui doivent être exécutés dans l'ordre

Monde Réel Exemple de la Stratégie de la tendance

Non, ils ne sont pas nécessairement consommés de la même manière. Le "modèle " méthode" est un moyen de fournir des "conseils" aux futurs maîtres d'œuvre. Vous leur dites, "tous les objets de personne doivent avoir un numéro de sécurité sociale" (c'est un exemple trivial, mais il obtient l'idée à travers correctement).

le schéma de stratégie permet multiples implémentations possibles pour être commuté dans et Hors. Il n'est pas (habituellement) mis en œuvre par héritage, mais au lieu de cela en laissant l'appelant passer dans l'implémentation désirée. Un exemple pourrait être de permettre à un calculateur D'expédition d'être fourni avec l'une de plusieurs façons différentes de calculer les impôts (une mise en œuvre de Nostaxes, et une mise en œuvre de PercentageBasedSalesTax peut-être).

ainsi, parfois, le client indiquera à l'objet quelle stratégie utiliser. Comme dans

myShippingCalculator.CalculateTaxes(myCaliforniaSalesTaxImpl);

mais le client ne ferait jamais cela pour un objet basé sur la méthode du modèle. En fait, le client pourrait même ne pas savoir qu'un objet est basé sur la méthode de Template. 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 cas réel exemple.

citation de l'article

" comme on peut le voir, la mise en œuvre des classes dépend également du modèle méthode de classe. Cette dépendance provoque la modification de la méthode du modèle si on veut changer certaines étapes de l'algorithme. Sur l'autre côté stratégie complètement encapsule l'algorithme. il donne l' implémenter des classes pour définir complètement un algorithme. Donc si tout changement arrive il faut changer le code pour précédemment écrit classes. C'est la raison principale pour laquelle j'ai choisi la stratégie la conception de la classe.

une caractéristique de la méthode du modèle est que la méthode du modèle contrôle algorithme. Qui peut être une bonne chose dans d'autres situations, mais dans mon ce problème c'était me restreindre pour concevoir les classes. Sur l'autre côté stratégie ne contrôle pas les étapes d'un algorithme qui permet de je dois ajouter des méthodes de conversion complètement différentes. Donc dans mon cas stratégie de m'aide pour la mise 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 cette l'article que j'ai à répéter le même code dans les quatre classes encore et encore. Par conséquent, il est difficile de maintenir parce que si la mise en œuvre de notre système comme l'étape 4, qui est commun à tous est changé alors je aura à jour toutes les 5 classes. De l'autre côté, dans méthode de modèle, je ne peux changer la superclasse et les changements sont reflétées dans les sous-classes. Par conséquent, la méthode du modèle donne une faible quantité de redondance et grande quantité de partage de code parmi les classe.

La stratégie permet également de modifier l'algorithme à l'exécution. Dans le modèle méthode de ré-initialiser l'objet. Cette fonction de la stratégie offre une grande flexibilité. Du point de conception de il faut préférer la composition à l'héritage. Par conséquent l'utilisation de modèle de stratégie est également devenu le premier choix pour le développement."

Le Modèle est similaire au modèle de Stratégie. Ces deux modèles diffèrent par leur portée et leur méthodologie.

est utilisée pour permettre aux appelants de faire varier un algorithme entier, comme la façon de calculer différents types de taxes, tandis que la méthode du modèle est utilisée pour faire varier les étapes d'un algorithme. Pour cette raison, la stratégie est plus grossière. Le modèle permet des contrôles à grain plus fin dans la séquence des opérations, et permet pourtant les implémentations de ces les détails varient.

l'autre grande différence est que la stratégie utilise la délégation tandis que la méthode du modèle utilise l'héritage. En stratégie, l'algorithme est délégué à une autre classe xxxStrategy à laquelle le sujet fera référence, mais avec Template vous sous-classe les méthodes de base et override pour faire des changements.

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

dans les sous-classes de patterns stratégiques exécutent le spectacle et ils contrôlent l'algorithme. Ici, le code est dupliqué dans les sous-classes. La connaissance de l'algorithme et de la façon de l'implémenter est répartie sur de nombreuses classes.

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

Template Pattern:

Template method consiste à laisser les sous-classes redéfinir certaines étapes de l'algorithme, sans changer la structure principale et les étapes de l'algorithme, défini dans la classe de base. Le modèle de modèle utilise habituellement l'héritage, de sorte qu'une implémentation générique des 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;
    }
}

Note dans le code ci-dessus, l'algorithme go () les étapes 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.

Stratégie:

schéma de stratégie est sur le fait de laisser le client choisit l'implémentation d'algorithmes concrets à l'exécution. Tous les algorithmes sont isolés et indépendants, mais mettent en œuvre une interface commune, et il n'y a aucune notion de définir des é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 source complète code, vérifiez mon github dépôt .

Schéma De Conception De La Stratégie

• soutient la composition.
• vous offre la flexibilité de changer le comportement de l'objet à l'exécution.
• moins de couplage entre le code client et le code solution/algorithme.

Template Method Design Pattern""

• favorise l'héritage sur composition
• définit l'algorithme dans votre classe de base. Des morceaux individuels d'algorithme peuvent être personnalisés dans les classes pour enfants.

est exposée en tant qu'Interface et la méthode de modèle en tant que classe abstraite. Cela est généralement beaucoup utilisé dans les cadres. par exemple La classe MessageSource de Spring framework 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 l'implémentation abstraite de la même interface AbstractMessageSource, qui a l'implémentation commune de résoudre des messages et expose la méthode resolveCode() abstract pour que les sous-classes puissent les mettre en œuvre à leur manière. 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 modèle de ce modèle de conception, une ou plusieurs étapes de l'algorithme peuvent être supplantées par des sous-classes pour permettre des comportements différents tout en s'assurant que l'algorithme global est toujours suivi(Wiki).

la méthode de modèle de nom de modèle signifie ce qu'elle est. Disons que nous avons une méthode CalculateSomething() et nous voulons modeler cette méthode. Cette méthode sera déclarée dans la classe de base non méthode virtuelle. Disons que la méthode ressemble à ça.

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 classes dérivées.

dans le schéma de stratégie 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 classe)

L'exemple classique est le tri. Basé sur le nombre d'objets doit être trié la classe d'algorithme appropriée(fusionner, bulle, rapide, etc.) est créé et l'algorithme entier est encapsulé dans chaque classe.

pouvons-nous maintenant mettre en œuvre la méthode de tri en tant que modèle? Certes, vous pouvez, mais vous ne trouverez pas beaucoup/n'importe quelle communauté à être abstraite et placée dans l'implémentation de base. Donc, il va à l'encontre du but du modèle de méthode de modèle.