Problema identificado:
En el código original existía una clara duplicación de clases y jerarquías redundantes (por ejemplo, tener la entidad Calzado y simultáneamente CalzadoReporte, o Empleado y EmpleadoReporte). Estas clases fueron creadas con el único propósito de añadir formatos de impresión y exportación a las entidades base. Esto viola directamente el Principio de Responsabilidad Única (SRP), infla el código innecesariamente y duplica el esfuerzo de mantenimiento, ya que cualquier cambio en la base de datos obligaba a modificar tanto la entidad original como su respectiva clase de reporte.
Solución propuesta e implementada:
Se implementó el patrón de diseño estructural Decorator para añadir funcionalidades de exportación de forma dinámica y en tiempo de ejecución, eliminando la necesidad de crear subclases para cada variación.
Se eliminaron todas las clases estáticas redundantes (CalzadoReporte, EmpleadoReporte, etc.) del paquete de entidades.
Se definió la interfaz base ComponenteReporte y la clase ReporteEstandar.
Se creó el decorador abstracto ReporteDecorator que envuelve al componente base.
Se implementaron los decoradores concretos ReportePDFDecorator y ReporteExcelDecorator para añadir el formato final únicamente cuando el usuario solicita la exportación.
Consecuencias e implicaciones del rediseño:
Se eliminó la explosión de clases y se respetó el Principio de Responsabilidad Única, dejando a las entidades puras y moviendo la lógica de exportación a sus propios componentes. El sistema ahora es altamente escalable; si en el futuro se requiere exportar a un nuevo formato (como CSV o XML), solo se debe crear un nuevo decorador sin tocar el código existente.
La instanciación del objeto en la capa de presentación puede ser un poco más verbosa, ya que requiere crear el componente base y luego "envolverlo" explícitamente con los decoradores necesarios antes de ejecutar el método de generación.
Problema identificado:
En el código original existía una clara duplicación de clases y jerarquías redundantes (por ejemplo, tener la entidad Calzado y simultáneamente CalzadoReporte, o Empleado y EmpleadoReporte). Estas clases fueron creadas con el único propósito de añadir formatos de impresión y exportación a las entidades base. Esto viola directamente el Principio de Responsabilidad Única (SRP), infla el código innecesariamente y duplica el esfuerzo de mantenimiento, ya que cualquier cambio en la base de datos obligaba a modificar tanto la entidad original como su respectiva clase de reporte.
Solución propuesta e implementada:
Se implementó el patrón de diseño estructural Decorator para añadir funcionalidades de exportación de forma dinámica y en tiempo de ejecución, eliminando la necesidad de crear subclases para cada variación.
Se eliminaron todas las clases estáticas redundantes (CalzadoReporte, EmpleadoReporte, etc.) del paquete de entidades.
Se definió la interfaz base ComponenteReporte y la clase ReporteEstandar.
Se creó el decorador abstracto ReporteDecorator que envuelve al componente base.
Se implementaron los decoradores concretos ReportePDFDecorator y ReporteExcelDecorator para añadir el formato final únicamente cuando el usuario solicita la exportación.
Consecuencias e implicaciones del rediseño:
Se eliminó la explosión de clases y se respetó el Principio de Responsabilidad Única, dejando a las entidades puras y moviendo la lógica de exportación a sus propios componentes. El sistema ahora es altamente escalable; si en el futuro se requiere exportar a un nuevo formato (como CSV o XML), solo se debe crear un nuevo decorador sin tocar el código existente.
La instanciación del objeto en la capa de presentación puede ser un poco más verbosa, ya que requiere crear el componente base y luego "envolverlo" explícitamente con los decoradores necesarios antes de ejecutar el método de generación.