Quand utiliser le motif d'usine abstrait?

Question

J'essaie de décrire succinctement quand pour utiliser une usine, pour moi-même et mon équipe. Je suis tombé sur des questions connexes suivantes, ce qui a permis un peu:

• When to use factory patterns?
  • (lien utile pdf est cassé)
• How do you create your Factories?
  • (plus 'comment' plutôt que 'quand')
• What is your threshold to use factory instead of a constructor to create an object?
  • (quelques réponses générales)
• Factory Pattern. When to use factory methods?
  • (plus sur les méthodes d'usine que les classes d'usine)
• When to use Factory method pattern?
  • (encore plus sur les méthodes d'usine)

Sur la base de ces liens, et un tas d'autres sources (voir la liste en bas), je suis venu avec les éléments suivants:

Quand utiliser l'abstrait modèle d'usine:

• lorsque vous utilisez une var interface ou l'opérateur 'nouveau'
  • par exemple. Utilisateur utilisateur = new ConcreteUserImpl();
• et le code que vous écrivez doit être testables/extensible à un moment donné

Explication:

• interfaces par leur nature impliquent de multiples implémentations (bon pour les tests unitaires)
• les variables d'interface impliquent le code compatible OCP et LSP (sous-classe de prise en charge)
• utilisation de la « nouvelle » brise opérateur OCP/DI, parce que les classes très couplées sont difficiles à tester ou modifier

« Est-ce que je crée une usine pour chaque type d'objet? Cela semble excessif."

• pas, vous pouvez avoir un (ou plusieurs) des usines qui produisent beaucoup de (généralement liés) types d'objets
• par exemple appFactory.createUser(); appFactory.createCatalog(), etc.

Quand ne pas utiliser une usine:

• le nouvel objet est très simple et peu susceptible d'être sous-classé
  • par exemple. Liste list = new ArrayList();
• le nouvel objet est pas intéressant de tester
  • n'a pas de dépendances
  • N'a pas de travail pertinente ou en cours d'exécution à long
  • par exemple Logger log = nouveau SimpleLogger();

Références:

• http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html
• http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
• http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
• http://en.wikipedia.org/wiki/Dependency_Injection
• http://en.wikipedia.org/wiki/Open_Closed_Principle
• http://en.wikipedia.org/wiki/Liskov_substitution_principle

---

Ma question est: est mon résumé exact, et est-il logique? Y a-t-il quelque chose que j'ai oublié?

Merci d'avance.

Answer 1

Résumé Le motif d'usine fournit un moyen d'encapsuler des usines concrètes qui partagent des points communs les unes avec les autres, ce qui signifie qu'elles implémentent la même interface/classe abstraite.

Vous devez utiliser le modèle d'usine lorsque vous souhaitez contrôler l'initialisation de vos objets, au lieu de donner le contrôle au consommateur.

Answer 2

Je dirais aussi ne pas utiliser une usine lorsque vous avez une implémentation particulière que vous voulez. Pour continuer l'exemple List, je sais que je veux un ArrayList parce que je fais un accès aléatoire. Je ne veux pas me fier à une usine qui a raison quand je peux le faire moi-même. Inversement, quand je ne veux pas connaître la sous-classe concrète, je peux utiliser une usine et la laisser s'inquiéter de l'objet à instancier.

Je suppose que je suggère que vous ajoutez une balle à la "quand utiliser le modèle d'usine abstraite" qui dit "et vous ne vous souciez pas vraiment quelle sous-classe concrète vous obtenez", et l'inverse de "quand pas utiliser une usine ". EDIT: Veillez à éviter le general-purpose tool-building factory factory factory.

Answer 3

En général, utilisez-le lorsque vous voulez pouvoir passer de l'implémentation à une configuration externe.

JDBC et JAXP sont d'excellents exemples. Pour plus d'exemples, vérifiez this answer.