Quelle est la différence entre les modèles Factory et Strategy?

Quelqu'un peut-il expliquer la différence entre les modèles d'usine et de stratégie?

Pour moi, les deux ont la même apparence, sauf une classe d'usine supplémentaire (qui crée un objet de produit dans des modèles d'usine)

Un modèle d'usine est un modèle de création. Un modèle de stratégie est un modèle opérationnel. En d'autres termes, un modèle d'usine est utilisé pour créer des objets d'un type spécifique. Un modèle de stratégie est utilisé pour effectuer une opération (ou un ensemble d'opérations) d'une manière particulière. Dans l'exemple classique, une usine pourrait créer différents types d'animaux: Chien, Chat, Tigre, tandis qu'un modèle de stratégie effectuerait des actions particulières, par exemple, Déplacer; en utilisant les stratégies Run, Walk ou Lope.

En fait, les deux peuvent être utilisés ensemble. Par exemple, vous pouvez avoir une fabrique qui crée vos objets métier. Il peut utiliser différentes stratégies basées sur le milieu de persistance. Si vos données sont stockées localement dans XML, elles utiliseraient une stratégie. Si les données étaient distantes dans une autre base de données, il en utiliserait une autre.

Le modèle de stratégie vous permet de changer polymorphiquement le comportement d'une classe.

Le modèle d'usine vous permet d'encapsuler la création d'objets.

Gary fait valoir un excellent point. Si vous utilisez le principe du codage d'abstractions plutôt que de "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 se ressemblent en ce qui concerne la mise en œuvre. Autrement dit, vous devez souvent créer une interface là où il n'y en avait peut-être pas auparavant dans votre code, puis créer un tas d'implémentations de cette interface. La différence réside dans leur objectif et dans la manière dont ils sont utilisés.

• Le modèle d'usine (méthode).

Créez uniquement des instances concrètes. Différents arguments peuvent aboutir à des objets différents. Cela dépend de la logique, etc.

• Le modèle de stratégie.

Encapsulez l'algorithme (étapes) pour effectuer une action. Vous pouvez donc changer de stratégie et utiliser un autre algorithme.

Bien que les deux semblent très similaires, le but est plutôt différent, un objectif est de créer l'autre est d'effectuer une action.

Alors. Si votre méthode Factory est corrigée, 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 ait besoin d'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.

Tout d'abord, il faut faire une différence entre l'usine simple et l'usine abstraite. La première est une simple fabrique où vous n'avez qu'une seule classe qui agit comme une fabrique 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éthodes) puis appelez les différentes usines qui implémentent cette interface qui sont censés avoir différentes implémentations de la même méthode en fonction de certains critères. Par exemple, nous avons une interface ButtonCreationFactory, qui est implémentée par deux usines, la première WindowsButtonCreationFactory (crée des boutons avec l'apparence Windows) et la seconde LinuxButtonCreationFactory (crée des boutons avec l'apparence Linux). Donc, ces deux usines ont la même méthode de création avec des implémentations différentes (algorithmes).

Par exemple, si vous voulez des boutons avec l'apparence Linux:

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 modèle de stratégie, car il différencie les algorithmes pour faire une certaine création. Cependant, il en diffère sémantiquement car il est utilisé pour la CRÉATION D'OBJETS plutôt que pour des algorithmes opérationnels. Donc, fondamentalement, avec l'usine abstraite, vous avez la création d'objets en utilisant différentes stratégies, ce qui la rend très similaire au modèle de stratégie. Cependant, la AbstractFactory est créative, tandis que le modèle de stratégie est opérationnel. En ce qui concerne la mise en œuvre, ils sont les mêmes.

Factory (et FactoryMethod retourné par Factory) :

1. Motif créatif
2. Basé sur l'héritage
3. Factory renvoie une méthode Factory (interface) qui à son tour renvoie un objet concret
4. Vous pouvez remplacer de nouveaux objets concrets pour l'interface et le client (l'appelant) ne doit pas être au courant de toutes les implémentations concrètes
5. Le client accède toujours à l'interface uniquement et vous pouvez masquer les détails de création d'objet dans la méthode Factory

Jetez un œil à cet article de wikipedia et à cet article javarevisited

Modèle de stratégie:

1. C'est un modèle de comportement
2. C'est basé sur la délégation
3. Cela change les tripes de l'objet en modifiant le comportement de la méthode
4. Il est utilisé pour basculer entre les familles d'algorithmes
5. Il modifie le comportement de l'objet au moment de l'exécution

Exemple:

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

Articles Similaires:

Exemple du monde réel du modèle de stratégie

Modèles de conception: méthode Factory vs Factory vs Abstract Factory

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

Le getCommand est la fabrique et les classes UnixCommand, WindowsCommand et OSXCommand sont des stratégies

Le modèle de stratégie en termes simples est plus une création de comportement à l'exécution où vous n'êtes pas concerné par la classe d'implémentation. De l'autre, had factory est la création à l'exécution d'une instance de classe concrète et c'est à vous d'utiliser n'importe quel comportement (méthode) exposé par l'interface implémentée.

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

Stratégie: "Définissez une famille d'algorithmes, encapsulez chacun d'eux et rendez-les interchangeables. La stratégie permet à l'algorithme de varier indépendamment des clients qui l'utilisent."

Méthode Factory: "Définissez une interface pour créer un objet, mais laissez les sous-classes décider quelle classe instancier. La méthode Factory permet à une classe de différer l'instanciation aux sous-classes."

Et voici une explication détaillée sur les intentions et les différences entre ces deux modèles: Différence entre les modèles de conception de méthode d'usine et de stratégie

Je peux faire une digression avec Oscar en ce que son exemple d'implémentation Factory est plutôt étroitement couplé et très fermé, pas étonnant que votre choix soit un modèle de stratégie. Une implémentation Factory ne doit pas dépendre d'un nombre fixe de classes spécifiques 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 les critères les plus appropriés pour choisir l'un ou l'autre sont principalement les termes que vous employez pour nommer vos classes et méthodes, en tenant compte que nous devrions tous avoir tendance à programmer sur des interfaces et non sur des classes et aussi à nous concentrer sur l'objectif: nous visons à déterminer quel code s'exécutera à l'exécution. Cela dit, nous pouvons atteindre l'objectif en utilisant l'un des deux modèles.

La stratégie et l'usine sont des objectifs différents. Dans la stratégie, vous avez défini l'approche, en utilisant ce modèle, vous pouvez échanger le comportement (algorithmes). En venant à l'usine, il existe de nombreuses variantes. Mais le modèle d'origine de l'usine d'états GO4 laisse la création de l'objet à la classe enfant. Ici, avec l'usine, vous remplacez l'instance complète et non le comportement qui vous intéresse. Vous remplacerez ainsi le système complet et non l'algorithme.

Le modèle d'usine est un modèle de création, qui est créé avec des propriétés (comportement) spécifiées. tandis qu'au moment de l'exécution après la création, vous ne changez pas ses propriétés (comportement). donc si vous avez besoin de différentes propriétés (comportement), vous devez supprimer l'objet et créer un nouvel objet avec les propriétés nécessaires (comportement). ce qui n'est pas gud. tandis qu'en cas de modèle de stratégie, vous pouvez modifier les propriétés (comportement) au moment de l'exécution.