2010-05-13 23 views
16

¿Cuáles serían las desventajas de usar el patrón de diseño del generador? ¿Hay alguno?desventajas del patrón de diseño del generador

editar - Deseo saber si hay alguna consecuencia negativa del uso del patrón de diseño del constructor. Como en el libro de GOF, han mencionado las consecuencias buenas y malas de los patrones de diseño. Pero no han mencionado ninguna mala consecuencia para el patrón de diseño del constructor.

+6

Esta pregunta no puede responderse sin contexto. ¿Qué problema estás tratando de resolver con el patrón del constructor? El patrón de generador es una forma de resolver ciertos problemas en lenguajes tipados estáticamente, pero no se puede usar para resolver otros problemas en el mismo idioma, por lo que es imposible decir si es "bueno" o "malo". –

+1

Depende. Si su clase parece que tendrá constrictores con más de un puñado de parámetros, entonces el patrón de diseño del constructor será una buena opción. Sin embargo, si el único propósito de la clase de su diseño es imprimir la cadena "Pantalones" en la pantalla, entonces es probable que se exceda ... –

Respuesta

13

Crea más código (y podría introducir más complejidad) en el DTO que si tuviera, por ejemplo, argumentos de contructor y/o setters/getters.

En mi opinión, esto no es un gran problema, en la mayoría de los casos no hay un montón de código adicional. El patrón del generador valdrá la pena si tiene un objeto que tiene algunos parámetros obligatorios y algunos opcionales.

+0

¿Qué quisiste decir con DTO? – Geek

+1

Objeto de transferencia de datos –

+0

Tema antiguo, sin embargo, no veo ninguna razón por la cual obligatorio u opcional deba ser un parámetro para decidir si debe usar este o aquel método para obtener el conjunto de datos. En los días en que las personas escribían código C/C++ simple, no teníamos todo esto. Supongo que sabíamos lo que estábamos haciendo. Naturalmente, las cosas avanzan, pero para mí, el patrón del constructor desordena sus clases, es más trabajo, hace que el código sea más difícil de leer y aumenta el mantenimiento. Lo he visto, comienza con un Constructor, luego hay un Constructor y Setters. Los 3 de ellos Y todo porque alguien escribió un libro llamado Effective Java. – Lawrence

9

Un patrón solo es una desventaja cuando se abusa o se usa indebidamente el patrón. Es decir. el patrón no resolvió/satisface el problema técnico/funcional real en absoluto. Debería entonces buscar otro patrón para resolver el problema particular.

Esto no se aplica específicamente al patrón del generador, sino a patrones de diseño en general.


actualización: si usted estaría interesado en aprender acerca de los distintos patrones de diseño (en concreto los que se mencionan en el libro Patrones GoF Design) y los ejemplos del mundo real en la API de Java, entonces usted puede encontrar este respuesta: Examples of GoF Design Patterns in Java's core libraries útil. Contiene enlaces a artículos de Wikipedia que explican los patrones en detalle.

+0

gracias por el enlace. Estoy interesado en aprender el patrón de diseño. Iré por el enlace dado. – agrawalankur

4

I segundo Jarle post.

lo demás, cuando se trata de desventajas:

  • El Builder no es un buen partido si tiene que asignar el DTO con, por ejemplo Hibernate o JAXB.
  • Si por alguna razón quiere un objeto mutable.
  • Para DTO pequeños con dos o tres campos, es solo por encima de la cabeza y debería usar un constructor o dos. A menos que sepa o crea que el DTO contendrá más campos en el futuro.
+0

-1, los 3 puntos son incorrectos. Un patrón de generador no tiene absolutamente nada que ver con la asignación de DB, ya sea mutable o no, el tercer punto de usted indica que no sabe realmente cuál es el propósito del patrón de generador. –

+1

@Angel: el marco de mapeo usualmente usa métodos y constructores establecidos para establecer diferentes valores para los objetos. ¿Alguna vez ha usado un marco de mapeo genérico antes? Sus dos últimos argumentos son bastante débiles. – Espen

+0

¿Y qué hace "setMethods" o "constructors" como se usa en los marcos de mapeo para hacer con el patrón del constructor? Correcto: _nothing_ Sugiero que lea la definición de GOF del patrón de generador. –

3

Builder, cuando se utiliza con la idea en mente para superar la falta de parámetros opcionales en Java, se pierde el análisis estático proporcionado por el compilador (y todas las características de refactorización agradables proporcionados por su IDE). Esto significa que usted va a detectar que algunos parámetros obligatorios faltan solamente en tiempo de ejecución, en lugar de tener su IDE que le dice inmediatamente que algo está mal ...

2

en comparación con los constructores de telescopios

  • pérdida de análisis estático
  • por faltar parámetros obligatorios una excepción necesita ser lanzado y atrapado somethere
  • si utiliza tipos encajonados en constructores para representar los valores primitivos y que no figuren todavía, entonces hay una gran cantidad de auto-boxing/unboxing pasando - que permite NullPointerExceptions que son difíciles de detectar. No existe tal problema en los constructores de telescopio; solo puede pasar los valores primitivos .
  • mucho más código
Cuestiones relacionadas