¿Cuándo utilizar el patrón abstracto de fábrica?

Question

Estoy tratando de describir sucintamente cuando para usar una fábrica, tanto para mí como para mi equipo. Me encontré con las siguientes preguntas relacionadas, lo que ayudó un poco:

• When to use factory patterns?
  • (útil pdf link está roto)
• How do you create your Factories?
  • (más 'cómo' en lugar de 'cuando')
• What is your threshold to use factory instead of a constructor to create an object?
  • (algunas respuestas generales)
• Factory Pattern. When to use factory methods?
  • (más sobre métodos de fábrica que las clases de fábrica)
• When to use Factory method pattern?
  • (otra vez más sobre métodos de fábrica)

Sobre la base de estos enlaces, y un montón de otras fuentes (que aparece en la parte inferior), yo he llegado con lo siguiente:

Al utilizar el resumen patrón de la fábrica:

• cuando se utiliza un var interfaz o el operador 'nuevo'
  • v.g. Usuario user = new ConcreteUserImpl();
• y el código que está escribiendo debe ser comprobable/extensible en algún momento

Explicación:

• las interfaces, por su propia naturaleza implican múltiples implementaciones (bueno para las pruebas unitarias)
• vars de interfaz implican código compatible con OCP y LSP (subclasificación de soporte)
• uso de la 'nueva' operador rompe OCP/DI, porque las clases acoplados altamente son difíciles de probar o cambiar

"puedo crear una fábrica para cada tipo de objeto? Eso parece excesivo."

• no, usted puede tener uno (o unos pocos) fábricas que producen una gran cantidad de (por lo general relacionados) tipos de objetos
• por ejemplo appFactory.createUser(); appFactory.createCatalog(); etc.

cuándo no usar una fábrica:

• el nuevo objeto es muy simple y poco probable que sea sub-clasificarse
  • p. List list = new ArrayList();
• el nuevo objeto no es interesante para probar
  • no tiene dependencias
  • realiza ningún trabajo pertinente o de larga duración
  • por ejemplo, Logger log = new SimpleLogger();

Referencias:

• 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

---

Mi pregunta es: ¿es mi resumen exacto, y ¿tiene sentido? ¿Hay algo que haya pasado por alto?

Gracias de antemano.

Answer 1

El patrón abstracto de fábrica proporciona una forma de encapsular fábricas de hormigón que comparten algunas características comunes entre sí, lo que significa que implementan la misma clase de interfaz/resumen.

Debe utilizar el patrón de fábrica cada vez que desee controlar la inicialización de sus objetos, en lugar de darle el control al consumidor.

Answer 2

También diría que no use una fábrica cuando tenga una implementación en particular que desee. Para continuar el ejemplo List, sé que quiero un ArrayList porque estoy haciendo un acceso aleatorio. No quiero depender de que una fábrica lo haga bien cuando puedo hacerlo yo mismo.

Por el contrario, cuando no quiero saber sobre la subclase concreta, entonces puedo usar una fábrica y dejar que se preocupe sobre qué objeto crear.

Supongo que le sugiero que agregue una viñeta al "cuándo usar el patrón abstracto de fábrica" ​​que dice "y realmente no le importa qué subclase concreta obtiene", y la inversa a "cuando no usar una fábrica ".

EDITAR: Tenga cuidado para evitar el general-purpose tool-building factory factory factory.

Answer 3

En general, úselo cuando desee poder cambiar de implementación mediante una configuración externa.

JDBC y JAXP son excelentes ejemplos. Para ver más ejemplos, marque this answer.