¿Debo usar siempre métodos de fábrica estáticos en lugar de constructores?

Lectura Efectivo Java, parece que hay muchas ventajas, y muy pocas desventajas, para usar métodos estáticos de fábrica. Por métodos de fábrica estáticas específicamente me refiero a la siguiente¿Debo usar siempre métodos de fábrica estáticos en lugar de constructores?

public class MyClass {  
    private MyClass() { ... }; 

    public static MyClass getInstance() { 
    return new A(); 
    }  
}

De Effective Java:

Tenga en cuenta que un método de fábrica estática no es el mismo que el patrón Factory Method partir de patrones de diseño [Gamma95, p. 107]. El método de fábrica estático descrito en este artículo no tiene equivalente directo en Patrones de diseño.

¿Ahora es mejor seguir siempre esta práctica, o solo algunas veces?

Si es así, ¿cuándo?

¿Alguna vez se ha hecho demasiado para hacer esto?

Fuente

2012-03-16 cendrillon

Es exagerado cuando es excesivo. Solo tú puedes juzgar eso. En general, te advierto que no sigas * ninguna * sabiduría recibida a ciegas. Por lo general, se descubre que todas las calificaciones originales con las que se cubrió la declaración original se olvidan, solo la regla permanece, a menudo nadie sabe realmente por qué. – EJP

En este caso, tenemos suerte ya que el texto original se conserva en todo su esplendor en el artículo 1 de Java efectivo. Pero no estoy seguro de si mi interpretación de esto es correcta. – cendrillon

Diría que generalmente es exagerado a menos que tenga un motivo específico para querer ocultar el tipo real que se está creando, que es básicamente cuando desea utilizar un patrón de fábrica. Sugiero que en la mayoría de los casos eso no es así. Considere cómo sería la vida, por ejemplo, si no pudiera construir un String o un Thread. – EJP

En general, los constructores son más simples que las fábricas, por lo que esta es una razón importante para elegir constructores en lugar de Fábrica. Use Factory cuando la situación lo requiera, no "por defecto". Debería hacer lo más simple que resuelva su problema, y la mayoría de las veces esto sería constructores.

Fuente

2012-03-16 05:54:01 Oleksi

Me gusta su razonamiento (la navaja de afeitar de Occam), sin embargo, me pregunto si hacer que el constructor sea público podría volver a picar más tarde. Una vez que su público ya no puede hacerse privado sin el riesgo de romper el código existente que ha hecho uso del constructor. Esto significa que la actualización posterior de un método de fábrica estático puede ser doloroso. También creo que podría haber problemas de seguridad de subprocesos también. No quiero cuestionar tu respuesta, pero me pregunto si hay algo más que esto. – cendrillon

Esto es una especie de área de llamada de juicio, pero un problema común es que los desarrolladores tienden a sobre-diseñar su código. Si bien es cierto que debes pensar en el futuro, debes considerar _cómo es probable_ que se requiera tal cambio. Entonces tienes que hacer una llamada de juicio. En general, aún diría que más simple es mejor. Esto es esencialmente un argumento para YAGNI: http://en.wikipedia.org/wiki/You_ain't_gonna_need_it – Oleksi

Este es un punto excelente. Me pregunto cómo equilibrar entre evitar el sobrediseño, por un lado, y una buena encapsulación, es decir, minimizar el acceso de las clases y los miembros. Es decir, el constructor siempre se puede hacer público, pero una vez que se publica debe ser público hasta el final de los tiempos. – cendrillon

Un enfoque de fábrica abstrae Creación y configuración de objetos del código que utiliza el objeto.

Si todo depende de la complejidad involucrada en la creación e inicialización del objeto. Si son simples, entonces no es necesario utilizar el patrón de fábrica.

Si es un poco complejo (implica muchos pasos en la inicialización antes de usarlo) y mejor vaya con el patrón de fábrica.

Fuente

2012-03-16 06:01:03 Santosh

¿Debo usar siempre métodos de fábrica estáticos en lugar de constructores?

Respuesta

Cuestiones relacionadas