Actualmente he creado una clase ABCFactory que tiene un único método para crear objetos ABC. Ahora que lo pienso, tal vez en lugar de tener una fábrica, podría hacer un método estático en mi Método ABC. ¿Cuáles son los pro y los contras para hacer este cambio? ¿No te llevará a lo mismo? No preveo que otras clases hereden ABC, ¡pero nunca se sabe!¿En qué casos tiene sentido usar clases de fábrica en lugar de funciones estáticas?
Gracias
En realidad, si desea obtener los beneficios de una clase de fábrica, necesita el método estático en su propia clase. Esto le permitirá luego crear nuevas clases de fábrica, o reconfigurar la existente para obtener diferentes comportamientos. Por ejemplo, una clase de fábrica podría crear unicornios que implementen la interfaz IFourHoovedAnimal. Es posible que tenga un algoritmo escrito que hace las cosas con IFourHoovedAnimal y necesita crear una instancia de ellos. Más tarde, puede crear una nueva clase de fábrica que, en su lugar, ejemplifique la versión de Pegaso, que también implementará la de IFourHoovedAnimal. El viejo algoritmo ahora puede ser reutilizado para Pegasus simplemente usando la nueva fábrica. Para que esto funcione, tanto PegasusFactory como UnicornFactory deben heredar de una clase base común (generalmente una clase abstracta).
Así que puede ver colocando el método estático en su propia clase de fábrica, puede cambiar las clases de fábrica por otras más nuevas para reutilizar los viejos algoritmos. Esto también funciona para mejorar la capacidad de prueba, porque ahora las pruebas unitarias pueden alimentarse en una fábrica que crea objetos falsos.
He hecho esto último antes (método de fábrica estático en la clase que está creando instancias) para proyectos muy pequeños, pero fue solo porque lo necesitaba para ayudar a refactorizar algunos códigos antiguos, pero mantener los cambios al mínimo . Básicamente, en ese caso, tuve en cuenta un fragmento de código que creó un grupo de controles ASP.NET, y metí todos esos controles en un control de usuario. Quería que mi nueva propiedad de control de usuario estuviera basada, pero era más fácil para el antiguo código heredado crear el control de usuario con un constructor basado en parámetros.
Así que creé un método de fábrica estático que tomaba todos los parámetros, y luego instanciaba el control de usuario y establecía sus propiedades en función de los parámetros. El antiguo código heredado usaba este método estático para crear el control del usuario, y el código futuro usaría las propiedades "más bonitas".
Para las clases concretas, métodos de fábrica son en realidad un método de direccionamiento indirecto alrededor de crear el tipo real (lo cual no quiere decir que no son útiles, pero como has encontrado, el método de fábrica realmente podría ser en cualquier parte).
Donde el método de fábrica realmente brilla es cuando su método crea instancias de un tipo de interfaz.
Tener un solo método estático hace que esto sea mucho más difícil de probar, mientras que tener un objeto instanciable permite que esto sea más fácil de probar. Además, la inyección de dependencia es más tarde una opción con la solución no estática.
Por supuesto, si no necesita nada de esto, estos no son buenos argumentos.
La principal ventaja del método de fábrica es la capacidad de ocultar la referencia a una clase específica detrás de una interfaz. Como los métodos estáticos no pueden formar parte de la interfaz, los métodos de fábrica estáticos son básicamente los mismos que el método constructor. La única aplicación útil de los métodos de fábrica estáticos es proporcionar acceso a un constructor privado, lo que se usa comúnmente para la implementación de patrones únicos.
+1 Corto y claro. –
La "D" en Uncle Bob's SOLID Principles of Object Oriented Design es "El principio de inversión de dependencia" Depende de las abstracciones, no de las concreciones.
Un seguimiento extremo de ese principio podría hacer que su clase principal cree todas sus fábricas, con cada fábrica usando otras fábricas a través de interfaces. La única apariencia de "nuevo" (creación de objetos concretos) estaría en su clase principal y sus fábricas. Todos sus objetos trabajarían con interfaces (abstracciones), con las dependencias concretas obtenidas de las implementaciones de fábrica suministradas.
Puede ajustar muy fácilmente o proporcionar múltiples clases principales personalizadas para diferentes escenarios.
El uso excesivo de patrones de diseño es peligroso, y los patrones de diseño creacional tienen sentido cuando tiene jerarquías de clase con interfaces definidas, o necesita construir objetos bastante complejos. Si tiene un diseño simple, use soluciones simples. Por lo tanto, en su caso, el método de fábrica sería suficiente
Sí, tienes razón, es otro patrón de diseño :)
¿Por qué es más fácil de probar con un método no estático? –
elysium @devoured: por ejemplo, una clase de prueba puede incluir una subclase del original que anula el método, para instrumentación o cortocircuito en el comportamiento normal. Eso no es (fácilmente) posible con un método estático. –
elysium @devoured - Porque no se puede pasar una clase estática como parámetro a los métodos de prueba (al menos no bien). Esto está relacionado con el segundo punto sobre la inyección de dependencia. Pero, como dijo Jaxidian, estos puntos pueden no ser importantes. –