cmenesess / poo Goto Github PK

En la clase materia el método escritor, casi no utiliza las variables de la clase materia, sino que utiliza solamente las variables de la clase pregunta. Por lo que se generaría un feature envy. Esto además generaría una baja cohesión entre la clase al no utilizar sus propios atributos de materia.

Beneficio
• Al hacer refactorización vamos a reducir el acoplamiento entre clases y elevaremos la cohesión dentro de la misma.
• Mejor organización del código (Los métodos para manejar el data van a estar alado de donde se encuentra la información)

Clase: Materia
Code Smell: Message Chains
• Problema presente

Este code smell implica una dependencia en la navegación a lo largo de la estructura de la clase.
Cualquier cambio en esas relaciones requiere una modificación en el cliente.
• Beneficios de Refactorizar
Reduce las dependencias a entre clases de la cadena.
Reduce la cantidad de código acoplado.
Esconde la delegación entre métodos al cliente.
Sección B

Sección C
Técnica de Refactorización usada: Hide Delegate
Esta técnica ayudara a esconder la implementación del cliente y será mas fácil de modificar si se hace algún cambio en algún método o clase dependiente.

Problema: La clase Estudiante.java instancia objetos que no tienen funcionalidad alguna más que acceso a sus datos para que sean usados por el sistema lo cual no aporta en gran medida y se tratan a los objetos de tipo Estudiante como conjuntos de datos.
Beneficios de Refactorizar: En teoría mejora la comprensión del código a futuro en caso de que el sistema llegue a escalar, se recopilarían todas las operaciones sobre estos objetos en un mismo lugar en lugar, en lugar de que estén dispersas por todo el código.

Al rebasar las 10 líneas de código para un método y este método Opcion1 al contar con 40 líneas daría como resultado el smelll code Long method. Este al ser demasiado largo va a ser difícil y cansado de entenderlo.

Beneficio
• El metodo va a ser mas entendible para el momento de que se desee hacer depuracion del codigo o algun cambio.
• Es mucho mejor utilizar metodos pequeños y con un buen nombre a que tener un metodo largo que sea cansado de leer.

En la imagen se observa como el constructor presenta un conjunto de variables relacionadas y como esto representa un problema al momento de querer añadir una nueva por lo que una posible solucion seria juntar todas estas variables en una clase para que el codigo quede asi:

Tal como se aprecia, con las variables agrupadas en una clase el codigo se vuelve mas legible y sobretodo no se ve afectado en caso de bien quitar una variable o agregar una nueva, para el constructor esto es transparente ya que la clase Opcion se encarga de ello.

En esta captura se observa como la clase CoolStack extiende de una clase con metodos que nunca va a usar incumpliendo el principio Liskov Substitution, una posible mejora seria:

Con la solución aplicada se evita que la clase CoolStack implemente métodos que no le sirven y los que si requiera simplemente puede invocarlos a través del objeto creado.

Buenas, en la clase MenuPrincipal se pudo observar un posible code smell Long class esto se debe a que se excedia mas de las 50 lineas para no considerar a alago long class pero en este caso utilizaba 864 lineas de codigo.Se puede observar que el MenuPrincipal tiene demasiadas responsabilidad, lo cual seria la principal razon de porque hay demasiadas lineas de codigo.

Beneficios de refactorizar:
Va a ser mas facil hacer un chequeo,mantenimiento o depuracion del codigo.Tambien se podran eliminar duplicacioon de codig y funcionalidad en caso de que existan.

Como se aprecia en la captura presentada, encontramos un code smell (comment) el cual representa un problema ya que el usuario que lo vea no va a entender la funcionalidad solo con el nombre del metodo, dicho esto presento una posible mejora:

Con esto el usuario entendera completamente la funcionalidad sin la necesidad de acceder a la clase para entender el metodo.