J'ai vu une implémentation d'usine à l'aide de méthodes statiques. Quelque chose comme ça: Je ne sais pas si je peux appeler cela abstrait usine, mais ce n'est pas la question. Ce que je comprends à propos de l'usine abstraite, c'est que cela nous donne la flexibilité de changer facilement les familles de produits. et si je veux passer à partir de alors quel est l'avantage de la mise en œuvre d'usine en utilisant des méthodes statiques? Ne perdons-nous pas la principale flexibilité? Qu'est-ce que j'ai manqué ici? Veuillez noter qu'aucune langue spécifique n'est supposée. Toute aide est appréciée. mysactory mysactory VotreFactory , une seule ligne est nécessaire pour changer. Je peux aussi changer cela au moment de l'exécution. Mais est-il possible de mettre en œuvre comme méthode statique? Je dois changer tous les appels en usine statique. Et aussi à utiliser si nous vérifions à tous les endroits si nous voulons décider du temps d'exécution.
5 Réponses :
J'étais sur le point de dire que je ne vois aucun avantage d'utiliser cette usine sur l'instanciation de vos objets via Cependant, ce n'est pas tout à fait correct. Vous pouvez choisir une implémentation pour une classe de base lorsque vous utilisez une telle usine, ce qui peut être la raison pour laquelle ils l'ont mis en œuvre. Par exemple, la méthode Je regarderai des réponses à cette question pour voir s'il existe d'autres utilisations pour une telle configuration, car je ne peux penser à rien d'autre pour le moment. nouveau produit1 () , etc.
CreateProduct1 () peut être implémentée comme renvoyer nouveau jumboproduct1 (); où jumboproduct1 est dérivé de produit1 et le reste du code sera isolé d'une telle décision politique. Pas très flexible, mais cela ferait le travail, je suppose.
Avec des méthodes statiques comme ça, vous obtenez une certaine réutilisation du code, mais c'est à peu près à l'ampleur de l'avantage. Il réduit essentiellement le modèle OO à un paradigme procédural. La grande chose que vous manquez à autre chose change votre implémentation à l'exécution basée sur le contexte.
Un singleton n'est que légèrement meilleur. Cela vous permet d'écrire votre logique normalement avec des variables de membre (état), puis simplement faire quelques modifications pour la transformer en singleton. Disons que vous faisiez une instance de mise en commun dans votre usine, un singleton pourrait être un bon ajustement là-bas. Vous manquez toujours sur le contexte cependant.
Le modèle le plus flexible consiste à utiliser l'inversion de dépendance, ce qui signifie que votre classe dépend d'une abstraction d'usine et ne sait pas ou si c'est un singleton ou non. Cela vous permet d'envisager le contexte lors de l'utilisation de l'usine concrète à utiliser.
Il n'y a pas d'avantages de l'usine abstraite ici. Seulement si cette méthode est un constructeur - Vous pouvez encapsuler une logique conditionnelle dans CreateProductX () Méthodes.
TaskInoor, L'utilisation de méthodes statiques n'est pas recommandée dans la programmation pure OO pour plusieurs raisons.
avoir dit qu'il y a peu d'avantages avec des méthodes statiques Si vous créez une bibliothèque de fonctions qui ont tendance à rester même au moment de l'exécution, les méthodes statiques sont un bon choix.
Veuillez consulter la mise en œuvre de l'usine abstraite ici. Je ne pense pas qu'il soit nécessaire d'utiliser des méthodes "statiques" pour obtenir une usine abstraite. http://www.dofactory.com/patterns/patternabstract.aspx#_self1
Pour la brièveté, l'utilisation d'une méthode statique pour instancier les objets est la plus propre si vous avez un grand nombre d'objets à configurer. Par exemple, Comparez:
textObject = TextUI.make("Code Example").move(50, 80).size(100, 200);
Etui d'utilisation réaliste pour la méthode de l'usine statique?