Quelle est la différence entre les modèles D'usine et de stratégie?

le schéma de stratégie vous permet de modifier polymorphiquement le comportement d'une classe.

le dessin d'usine vous permet d'encapsuler la création d'objet.

Gary marque un point. Si vous utilisez le principe de codage à des abstractions plutôt que des "concrétions" alors beaucoup de modèles commencent à ressembler à des variations sur un thème.

juste pour ajouter à ce que tvanfosson a dit, beaucoup de modèles ressemblent à la mise en œuvre. Qui est, beaucoup vous avez créer une interface où peut-être il n'y avait pas d'avant, dans votre code, puis créer un groupe d'implémentations de cette interface. La différence est dans leur but et comment ils sont utilisés.

• L'Usine ( méthode ).

ne Créer que des instances concrètes. Différents arguments peuvent entraîner différents objets. Il dépend de la logique etc.

• Le Modèle De Stratégie.

Encapsuler l'algorithme ( étapes ) pour effectuer une action. Donc vous pouvez changer la stratégie et utiliser un autre algorithme.

alors que les deux semblent très similaires, le but est assez différent, un but est de créer l'autre est d'effectuer une action.

So. Si votre méthode D'usine est fixe, vous pouvez l'avoir comme ceci:

 public Command getCommand( int operatingSystem ) { 
      switch( operatingSystem ) { 
           case UNIX    :
           case LINUX   : return new UnixCommand();
           case WINDOWS : return new WindowsCommand();
           case OSX     : return new OSXCommand();
       }
  }

mais supposons que votre usine nécessite une création plus avancée ou dynamique. Vous pouvez ajouter à la méthode d'usine une stratégie et la modifier sans avoir à recompiler, la stratégie peut changer à l'exécution.

il faut D'abord faire la différence entre l'usine simple et l'usine abstraite. La première est une simple usine où vous n'avez qu'une classe qui agit comme une usine pour la création d'objet, tandis que dans la seconde vous vous connectez à une interface d'usine (qui définit les noms de méthode) et puis appelez les différentes usines qui mettent en œuvre cette interface qui sont supposées avoir des implémentations différentes de la même méthode basée sur certains critères. Par exemple, nous avons un ButtonCreationFactory interface, qui est implémentée par deux usines, la première WindowsButtonCreationFactory (crée des boutons avec Windows look and feel) et la seconde LinuxButtonCreationFactory (crée des boutons avec Linux look and feel). Ces deux usines ont donc la même méthode de création avec des implémentations (algorithmes) différentes. Vous pouvez faire référence à cela dans runtime basé sur la méthode que vous tapez le bouton que vous voulez.

par exemple si vous voulez des boutons avec Linux regarder et se sentir:

ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);

ou si vous voulez des boutons Windows

ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);

exactement dans ce cas, il en résulte une sorte de schéma de stratégie, car il différencie des algorithmes pour faire une certaine création. Cependant, il diffère de lui sémantiquement parce qu'il est utilisé pour la création D'objet plutôt que des algorithmes opérationnels. Donc, fondamentalement avec abstract factory vous avez la création d'objet en utilisant différentes stratégies, ce qui le rend très similaire pour le modèle de stratégie. Cependant L'AbstractFactory est créatif, tandis que le schéma de stratégie est opérationnel. La mise en œuvre du sage, ils le résultat soit le même.

de l'Usine (et FactoryMethod retourné en Usine) :

1. Creational modèle
2. basé sur l'héritage
3. Usine renvoie une Méthode de Fabrique (interface) qui à son tour renvoie Objet Concret
4. vous pouvez substituer de nouveaux objets concrets pour l'interface et le client (appelant) ne doit pas être au courant de toutes les implémentations concrètes
5. le Client est toujours accès interface seulement et vous pouvez cacher les détails de création d'objet dans la méthode D'usine

regardez cet article Wikipédia et article javarisé

schéma de stratégie:

1. C'est un comportement
2. Il est basé sur la délégation
3. il change les boyaux de l'objet par modification du comportement de la méthode
4. il est utilisé pour passer d'une famille d'algorithmes à une autre
5. il modifie le comportement de l'objet au temps d'exécution

exemple:

vous pouvez configurer la stratégie de réduction pour un article particulier ( billet D'avion ou article ShoppingCart). Dans cet exemple, vous offrirez 25% de réduction à un article pendant juillet - décembre et aucune réduction sur l'article pendant Jaunaire - juin.

articles connexes:

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

Modèles de Conception: l'Usine de vs méthode de Fabrique vs Abstract Factory

pour prolonger ce Qu'Oscar a dit et en référence à son code:

La getCommand est l'Usine et de la UnixCommand, WindowsCommand et OSXCommand classes sont des Stratégies

schéma de stratégie en termes simples est plus de création runtime de comportement où vous n'êtes pas concerné par la classe d'implémentation. Sur l'autre usine avait est runtime création d'instance de classe de béton et c'est à vous d'utiliser n'importe quel comportement(méthode) exposé par l'interface implémentée.

je peux faire une digression avec Oscar dans le fait que son exemple d'une implémentation en usine est plutôt étroitement couplé et très fermé, pas étonnant que votre choix soit un modèle de stratégie. Une implémentation D'usine ne devrait pas dépendre d'un nombre fixe de classes spécifiques étant instanciées, par exemple:

public Command getCommand( int operatingSystem ) {        
   return commandTable.get(operatingSystem); 
}

...

public class WindowsCommand implements Command {
    ...
    static {
        CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
    }

}

je suppose que le critère le plus approprié pour choisir l'un ou l'autre est la plupart du temps les Termes que vous employez pour nommer vos classes et méthodes, en tenant compte que nous devrions tous tendre programmer aux interfaces et non aux classes et se concentrer aussi sur le but: nous visons à déterminer quel code s'exécutera à l'exécution. Cela dit, nous pouvons atteindre l'objectif en utilisant l'un de ces deux schémas.

la stratégie et L'usine sont des buts différents. Dans la stratégie vous avez l'approche définie, en utilisant ce modèle vous pouvez échanger le comportement (algorithmes). Venir à L'usine il ya beaucoup de variations autour. Mais le modèle original de GO4 states factory laisse la création de l'objet à la classe de l'enfant. Ici, avec l'usine de remplacement d'instance complète pas le comportement qui vous intéresse. Par ceci vous remplacerez le système complet pas l'algorithme.

dessin D'usine est un dessin de création, qui est créé avec des propriétés spécifiées(comportement). pendant que le temps d'exécution après la création ne change pas ses propriétés (comportement). donc si u a besoin de propriétés différentes (comportement) u doit supprimer l'objet et créer un nouvel objet avec les propriétés nécessaires(comportement). ce qui n'est pas gud. tandis que dans le cas du modèle de stratégie u peut changer les propriétés(comportement) au temps d'exécution.

Vous ne pouvez pas comprendre la différence simplement en regardant le code ou la catégorisation. Pour saisir les motifs GoF correctement, cherchez leurs intentions:

Stratégie": Définir une famille d'algorithmes, encapsuler chacun, et de les rendre interchangeables. La stratégie permet à l'algorithme de varier indépendamment des clients qui l'utilisent."

méthode D'usine: "définir une interface pour créer un objet, mais laisser les sous-classes décider quelle classe instantiate. Usine Méthode permet à une classe de reporter l'instanciation des classes."

et voici une explication élaborée sur les intentions et les différences entre ces deux modèles: différence entre la méthode D'usine et les modèles de conception de stratégie