**Descripción: **
Problema identificado: En el código original, el proceso de creación y registro de una venta estaba disperso dentro de la interfaz gráfica (Pnl_Content_Venta). El sistema intentaba unir las entidades Boleta_Cabecera y Boleta_Detalle paso a paso utilizando múltiples métodos setters manuales. Esta práctica acoplaba la vista a la lógica de negocio y corría el riesgo de crear ventas incompletas (por ejemplo, registrar una cabecera sin detalles si ocurría un error a la mitad del proceso), lo que podría causar corrupción de datos o inconsistencias de datos.
Solución propuesta e implementada: Se implementó el patrón de diseño creacional Builder para encapsular y centralizar la construcción de la boleta de venta.
- Se creó la clase envoltorio BoletaCompleta para manejar la cabecera y el detalle como una sola unidad de datos segura.
- Se definió la interfaz VentaBuilder y su implementación concreta BoletaEstandarBuilder, la cual contiene la lógica para ensamblar la cabecera.
- Se creó la clase VentaDirector para orquestar los pasos de construcción en un orden estricto.
- Se limpió la interfaz gráfica (Pnl_Content_Venta), delegando parte de la responsabilidad de creación al Director y obteniendo un objeto validado antes de interactuar con la base de datos.
Consecuencias e implicaciones del rediseño:
• Se garantiza la consistencia transaccional de los datos antes de enviarlos al DAO. Se respeta el patrón MVC aislando la interfaz gráfica (Vista) de la complejidad de construcción de los objetos (Modelo). El sistema asegura que siempre se reciba un objeto completamente válido.
• Aumenta la cantidad de clases en el proyecto. Para ensamblar un objeto que antes se hacía de forma directa, ahora el flujo de ejecución debe atravesar el Director y el Constructor.
**Descripción: **
Problema identificado: En el código original, el proceso de creación y registro de una venta estaba disperso dentro de la interfaz gráfica (Pnl_Content_Venta). El sistema intentaba unir las entidades Boleta_Cabecera y Boleta_Detalle paso a paso utilizando múltiples métodos setters manuales. Esta práctica acoplaba la vista a la lógica de negocio y corría el riesgo de crear ventas incompletas (por ejemplo, registrar una cabecera sin detalles si ocurría un error a la mitad del proceso), lo que podría causar corrupción de datos o inconsistencias de datos.
Solución propuesta e implementada: Se implementó el patrón de diseño creacional Builder para encapsular y centralizar la construcción de la boleta de venta.
Consecuencias e implicaciones del rediseño:
• Se garantiza la consistencia transaccional de los datos antes de enviarlos al DAO. Se respeta el patrón MVC aislando la interfaz gráfica (Vista) de la complejidad de construcción de los objetos (Modelo). El sistema asegura que siempre se reciba un objeto completamente válido.
• Aumenta la cantidad de clases en el proyecto. Para ensamblar un objeto que antes se hacía de forma directa, ahora el flujo de ejecución debe atravesar el Director y el Constructor.