java - desventajas del patrón de diseño del constructor

oop design-patterns

Question

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

editar: quiero saber si hay alguna mala consecuencia de usar el patrón de diseño del constructor. Al igual que en el libro de GOF, han mencionado las buenas y malas consecuencias de los patrones de diseño. Pero no han mencionado ninguna mala consecuencia para el patrón de diseño del constructor.

Answer 1

El patrón de generador, cuando se usa con la idea en mente para superar la falta de parámetros opcionales en Java, se pierde el análisis estático provisto por el compilador (y todas las características de refactorización proporcionadas por su IDE). Esto significa que detectará que faltan algunos parámetros obligatorios solo en tiempo de ejecución, en lugar de que su IDE le diga inmediatamente que algo está mal ...

Answer 2

Un patrón solo es desventajoso cuando el patrón ha sido abusado / mal utilizado. Es decir, el patrón no resolvió / se ajustó en absoluto al problema técnico / funcional real. A continuación, debe buscar otro patrón para resolver el problema en particular.

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

Actualización : si le interesaría conocer los diversos patrones de diseño (específicamente los mencionados en el libro de Patrones de diseño de GoF) y los ejemplos del mundo real en la API de Java, puede encontrar esta respuesta: Ejemplos de patrones de diseño de GoF en Java bibliotecas de núcleo útiles. Contiene enlaces a artículos de Wikipedia que explican los patrones en detalle.

Answer 3

Yo segundo la post de Jarle.

De lo contrario, cuando se trata de desventajas:

• El patrón de construcción no es una buena coincidencia si tiene que asignar el DTO, por ejemplo, con Hibernate o JAXB.
• Si por alguna razón quieres un objeto mutable.
• Para las DTO pequeñas con dos o tres campos, es solo una sobrecarga y debería usar un constructor o dos. A menos que sepa / crea que el DTO contendrá más campos en el futuro.

Answer 4

comparando a los constructores de telescopios

• pérdida de análisis estático
• para los parámetros obligatorios faltantes, se debe lanzar y capturar una excepción en algún lugar
• Si utiliza tipos encuadrados en los constructores para representar valores primitivos que aún no están establecidos, entonces hay una gran cantidad de auto-boxing / unboxing en marcha, lo que permite NullPointerExceptions que son difíciles de detectar. No existe tal problema en los constructores de telescopios: puede pasar valores primitivos.
• mucho más código

Answer 5

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 configuradores / captadores.

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