oop - sustantivo - ¿Cuándo usar el patrón abstracto de fábrica?
ejemplos de sustantivos dependientes (3)
El patrón Abstract Factory proporciona una manera 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 / abstracta.
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.
Intento describir sucintamente cuándo utilizar una fábrica, tanto para mí como para mi equipo. Me encontré con las siguientes preguntas relacionadas, que me ayudaron un poco:
- Cuándo usar patrones de fábrica?
- (el enlace pdf útil está roto)
- ¿Cómo se crean sus fábricas?
- (más "cómo" que "cuándo")
- ¿Cuál es su umbral para usar fábrica en lugar de un constructor para crear un objeto?
- (algunas respuestas generales)
- Patrón de fábrica. Cuándo usar los métodos de fábrica?
- (más sobre los métodos de fábrica que las clases de fábrica)
- ¿Cuándo usar el patrón de método de fábrica?
- (de nuevo más sobre los métodos de fábrica)
Con base en estos enlaces, y un montón de otras fuentes (enumeradas en la parte inferior), he encontrado lo siguiente:
Cuándo usar el patrón abstracto de fábrica:
- cuando usa una interfaz var o el operador ''nuevo''
- por ejemplo, Usuario usuario = nuevo ConcreteUserImpl ();
- y el código que está escribiendo debe ser comprobable / extensible en algún punto
Explicación:
- las interfaces por su propia naturaleza implican múltiples implementaciones (buenas para pruebas unitarias)
- los vars de interfaz implican código compatible con OCP y LSP (subclasificación de soporte)
- el uso del operador ''nuevo'' rompe OCP / DI, porque las clases altamente acopladas son difíciles de probar o cambiar
"¿Creo una fábrica para cada tipo de objeto? Eso parece excesivo".
- no, puede tener una (o algunas) fábricas que produzcan muchos tipos de objetos (generalmente relacionados)
- 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-clasificado
- por ejemplo, List list = new ArrayList ();
- el nuevo objeto no es interesante para probar
- no tiene dependencias
- no realiza trabajos relevantes 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 correcto mi resumen y tiene sentido? ¿Hay algo que haya pasado por alto?
Gracias por adelantado.
También diría que no use una fábrica cuando tenga una implementación particular que desee. Para continuar con el ejemplo de la List
, sé que quiero una 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 acerca de la subclase concreta, puedo usar una fábrica y dejar que se preocupe sobre qué objeto crear.
Supongo que sugeriría 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 "cuándo no usar una fábrica". ".
EDITAR: tenga cuidado de evitar la fábrica de factorías fábrica de construcción de herramientas de uso general .
En general, úsela cuando desee poder cambiar de implementación mediante una configuración externa.
JDBC y JAXP son excelentes ejemplos. Para ver más ejemplos, verifica esta respuesta .