tavo1987 / gym Goto Github PK

Se puede usar el patrón Decorator en la clase Fechas ya que hay métodos adicionales de la fecha normalmente por ende estos métodos serían una función adicional a la clase base que sería la clase fecha, es decir, se utiliza el patrón Decorator para agregar características adicionales a un objeto de manera flexible y modular, sin necesidad de modificar la estructura de la clase original.

Una posible solución de implementación Decorator podrías ser la siguiente:

En la clase de Reportes podrías implementar el patrón de diseño Strategy ya que de está forma se puede cambiar la estrategia de generar el reporte y si en un futuro se desea agregar una nueva opción para generar un reporte este no afectaría ya que no se modificaría el código existente, siendo así un código flexible.
Una solución podría ser la siguiente, se separo en reporte y reportecliente ya que no va a compartir la misma información.

En la clase Fecha no se cumple el principio de open-closed (OPC) y en parte el principio de responsabilidad simple (SRP), ya que la clase Fecha además de encargarse de la recepción del día, mes y año, se está encargando de la creación del formato de dichas fechas a fecha latina y fecha europea. ¿Y si se requiere presentar la fecha en el formato asiático, africano, o algún país que tiene su propio formato de fecha? Si seguimos para haciendo métodos por cada formato de fecha, sobrecargaríamos aún más la clase. Para cumplir con OCP y SRP en la clase Fecha se propuso crear el método abstracto getFecha () para que pueda ser sobrescrito en las clases hijas de la clase Fecha, así podremos crear tantas clases de acuerdo al formato de fecha de un determinado continente o país. De esta manera, hacemos que el código sea abierto a extensiones y cerrado modificaciones.

• Rediseño Clase Fecha
  

• Nueva clase: FechaLatina
  

• Nueva clase: FechaEuropea
  

• Diagrama: Rediseño clase Fechas
  

Por otra parte, la clase Foto está dependiendo de una clase de bajo nivel que se encarga de conectar el programa con la base de datos SQL, la cual se está instanciando en el constructor de la clase Foto y utilizando posteriormente. Para que clase Foto cumpla con el principio de dependencia inversa (DIP), como primer paso debemos depender de abstracciones en lugar de elementos concretos.

• Interfaz ConexionInterface
  

• Clase Conexión
  

De esta forma estamos adicionando una capa de abstracción a nuestra aplicación, la cual nos permite depender únicamente de la interfaz en lugar de su implementación concreta. Posteriormente, debemos evitar crear las clases concretas en el constructor de la clase Foto de tal manera que estas sean pasadas desde el constructor.

• Implementación en la clase Foto
  

• Diagrama: Rediseño clase Foto
  

Las clases Cliente, Pagos, Membresia y Ficha tienen responsabilidades que no les corresponde, ya que esas clases solo se encargan del manejo de información, pero también se las esta haciendo responsable de buscar, eliminar, actualizar o agregar información en la base de datos. Por tanto, para cumplir con el principio de responsabilidad simple (SRP), debe crear clases adicionales para que contengan las operaciones que se deben realizar en la base de datos.

• Clases para operaciones

• Clase Cliente

• Clase PagoOP

• Clase MembresiaOP

• Diagrama: Rediseño clase Cliente
  

• Diagrama: Rediseño clase Pagos
  

• Diagrama: Rediseño clase Membresia
  

Solución clase Cliente:

Para cumplir con el principio DIP, se debería introducir una abstracción o una interfaz que represente la funcionalidad de acceso a la base de datos en lugar de depender directamente de la clase Conexion. Luego, se podría inyectar esta abstracción en la clase Cliente a través de la inyección de dependencias, lo que permitiría que la clase Cliente dependa de una abstracción en lugar de una implementación concreta de acceso a la base de datos.

Se adjunta un diagrama UML