Quelqu'un peut-il expliquer la différence entre les modèles de fabrique et de stratégie ?
Pour moi, les deux sont identiques, à part une classe de fabrique supplémentaire (qui crée un objet de produit dans les modèles de fabrique).
Quelqu'un peut-il expliquer la différence entre les modèles de fabrique et de stratégie ?
Pour moi, les deux sont identiques, à part une classe de fabrique supplémentaire (qui crée un objet de produit dans les modèles de fabrique).
Un modèle d'usine est un modèle de création. Un pattern de stratégie est un pattern opérationnel. En d'autres termes, un factory pattern est utilisé pour créer des objets d'un type spécifique. Un patron 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 peut créer différents types d'animaux : Chien, Chat, Tigre, tandis qu'un patron de stratégie effectuerait des actions particulières, par exemple, se 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 usine qui crée vos objets d'entreprise. Elle peut utiliser différentes stratégies en fonction du support de persistance. Si vos données sont stockées localement en XML, elle utilisera une stratégie. Si les données étaient distantes dans une autre base de données, elle en utiliserait une autre.
Le modèle de stratégie vous permet de modifier de manière polymorphe le comportement d'une classe.
Le modèle de fabrique permet d'encapsuler la création d'objets.
Gary fait un excellent point. Si vous utilisez le principe de codage vers des abstractions plutôt que des "concrétions", alors beaucoup de modèles commencent à ressembler à des variations sur un thème.
Pour ajouter à ce que tvanfosson a dit, beaucoup de modèles se ressemblent en termes de mise en œuvre. C'est-à-dire qu'un grand nombre d'entre eux vous demandent de créer une interface là où il n'y en avait peut-être pas auparavant dans votre code, puis de créer un ensemble d'implémentations de cette interface. La différence réside dans leur objectif et dans la manière dont ils sont utilisés.
Tout d'abord, il faut faire la différence entre une fabrique simple et une fabrique abstraite. La première est une factory simple où vous n'avez qu'une seule classe qui agit comme une factory pour la création d'objets, alors que dans la seconde vous vous connectez à une interface factory (qui définit les noms des méthodes) et ensuite vous appelez les différentes factories qui implémentent cette interface qui sont supposées 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 de Windows) et la seconde LinuxButtonCreationFactory (crée des boutons avec l'apparence de Linux). Ces deux fabriques ont donc la même méthode de création avec des implémentations (algorithmes) différentes. Vous pouvez y faire référence en cours d'exécution en fonction de la méthode correspondant au type de bouton que vous souhaitez.
Par exemple, si vous voulez des boutons avec une 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 patron de stratégie, puisqu'il différencie les algorithmes pour faire une certaine création. Cependant, il en diffère sémantiquement car il est utilisé pour la CREATION d'OBJETS plutôt que pour des algorithmes opérationnels. Donc, fondamentalement, avec l'abstract factory, vous avez la création d'objets en utilisant différentes stratégies, ce qui le rend très similaire au strategy pattern. Cependant, l'AbstractFactory est créative, alors que le Strategy pattern est opérationnel. Au niveau de l'implémentation, les résultats sont les mêmes.
Créez uniquement des instances concrètes. Des arguments différents peuvent donner lieu à des objets différents. Cela dépend de la logique, etc.
Encapsuler l'algorithme (étapes) pour réaliser une action. Ainsi, vous pouvez modifier la stratégie et utiliser un autre algorithme.
Bien que les deux se ressemblent beaucoup, leur objectif est assez différent, l'un visant à créer, l'autre à effectuer une action.
Donc, si votre méthode Factory 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 ait besoin d'une création plus avancée ou dynamique. Vous pouvez ajouter à la méthode de la fabrique une stratégie et la modifier sans avoir à recompiler, la stratégie peut changer au moment de l'exécution.
Je ne pense pas que vous fassiez un bon point ici. Tout d'abord, une des raisons de ces patterns est d'éviter les conditionnels en faveur du polymorphisme. Tout d'abord, il faut faire la différence entre une fabrique simple et une fabrique abstraite.d La première est une fabrique simple où vous n'avez qu'une seule classe qui agit comme une fabrique pour la création d'objets, tandis que dans la seconde vous vous connectez à une interface et ensuite vous appelez les différentes fabriques qui implémentent cette interface qui sont censées avoir différentes implémentations de la même méthode en fonction de certains critères. (suite)
Exactement dans ce cas, il en résulte une sorte de modèle de stratégie, mais il en diffère sémantiquement car il est utilisé pour la CREATION d'OBJETS plutôt que pour des opérations. Donc, fondamentalement, vous avez une création d'objet utilisant des stratégies différentes.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Il y a d'autres bonnes réponses ici. softwareengineering.stackexchange.com/questions/405688/ . Celui de @Berin Loritsch , aidera à saisir la véritable force et la différence de la stratégie par rapport à l'usine,