Falta de uso de Patrones de diseño

[gabreilAlexKH]

Este mensaje es para propósitos educativos

El modelo de garaje presentado en este repositorio podría ser mejorado con la aplicación de patrones de diseño. Con el propósito de incrementar su flexibilidad y facilitar las expansión de sus funcionalidades.

Patron Builder
El repositorio hace uso de un Constructor con condicionales para crear diferentes tipos de autos, pero esto es una mala práctica que vuelve al constructor inflexible, y fuerza a modificar toda la clase Coche cada ves que se quiere agregar uno nuevo.

El diagrama de clases prestando da una propuesta del patrón Builder para el repositorio. Primero con el uso de herencia se han creado dos nuevas subclases de autos Caminon y TodoTerreno, solo dejando en auto los atributos que estos comparten. En ves de un constructor de la clase, el proceso de creación de los Autos de han dividido en pasos que la clase AutoDirecto usara para construir los autos, según cual clase que implemente AutoConstructor se le pase.

Ahora si se desean agregar nuevos vehículos mas complejos, solo de deben crear un clase que implemente a AutoConstructor en ves de cambiar al constructor de Autos. Desde el punto de vista del Cliente el proceso es mas largo, pero se gana flexibilidad a largo plazo y la capacidad de reutilizar varias veces los AutoConstructores y el AutoDirector. Los autos resultantes tienen características mas complejas como diferentes potencias y niveles de aceite.

Patron Decorator
En el main de repositorio el garaje no provee realmente un proceso de reparación y este debe ser hecho manualmente uno por uno en la clase main Prueba. Esto no refleja el verdadero funcionamiento de una mecánica o garaje como se lo llama en el repositorio.

El diagrama presenta al patrón Decorator aplicado al proceso de reparación de las averías. Un decorador permite dinámicamente agregar funcionalidades a un clase mediante la agregación. En este caso al Mecánico se le pueden agregar diferentes RepardaroAverias que le den la capacidad de repara una nueva a averías. Es decir con cada clase que se la agrega, el método repararAveria() de cada uno será ejecutado.

Garaje compone estas agregaciones con su método equiparMacanico, según los enum Averia pasadas como parámetro. Después con su método repararAutos() ejecutara el reparaAverias() de cada Reparador, lo cual ejecutara la implementación del método correspondiente a los ReparadroAverias() que se hayan agregado a mecánico. Desde el punto de vista del usuario, este solo debe pasar su auto y un ArrayList<> con las Averias de Auto.

Quitando la responsabilidad del cliente de reparar los autos, soportando ejecutar mas de una reparación de avería a la vez y haciendo el proceso de reparación reutilizable. Además de querer agregar la capacidad de reparas más averías, solo se deberían crear nuevas subclases de ReparadorAverias , nuevo enum de Averia y ajustes a equiparMacanico() en Garaje.

Una version de este repositiorio con los patrones incormporados se encuentra en esta link: https://github.com/gabreilAlexKH/Refractor_Modelo-Garaje-POO-Java.git
Para mas informacion sobre los patrones de diseño referirse a: https://refactoring.guru/es/design-patterns

Nota
Si bien en un repositorio pequeño no es tan importante el uso de Patrones de diseño, conforma los programas van creciendo en tamaño y complejidad su importancia se vuelve fundamental para asegurar su facilidad de expansión. Por esto considero que es una buena práctica tener una base solida de los patrones e incorpóralos incluso en este tipo de repositorios.
Es por la poca importancia que se le da la diseño al inicio que después los programas cresen en rígidos y complejos sistemas con un alto costo de mantenimiento , propensos a fallos y difíciles de modificar.