Refuerzo de refactorización

Para este refuerzo, vamos a utilizar el siguiente proyecto de ejemplo: Proyecto Scrum

Dicho proyecto, queda descrito en el siguiente diagrama:

Diagrama UML del proyecto Scrum

Este proyecto tiene muchos defectos a propósito. Por ejemplo:

  • Clases muy grandes: Contamos con clases muy grandes, como Tarea, que tiene muchos atributos y muchos métodos
  • Clases con más de una responsabilidad: Si observamos otra vez la clase Tarea, veremos que combina conceptos diferentes (incluye los datos de la persona responsable).
  • Hay código repetido: Hay muchos métodos y atributos repetidos en las clases HistoriaUsuario y Tarea

Nuestro objetivo es aplicar diferentes patrones de refactorización para obtener un diseño como el siguiente:

Diagrama UML del proyecto Scrum refactorizado

Aunque sigue sin ser perfecto, hemos resuelto los problemas comentados anteriormente.

Resumen de las refactorizaciones aplicadas

Separar Tarea en dos clases: Tarea y Persona

  1. Extraer la clase Persona de la clase Tarea
  2. Eliminar manualmente métodos setIdResponsable, getIdResponsable, setNombreResponsable, getNombreResponsable, setApellidosResponsable, getApellidosResponsable de la clase Tarea
  3. Añadir métodos getResponsable, setResponsable en Tarea
  4. Introducir parámetro del objeto en el constructor de Tarea para que idResponsable, nombreResponsable, ApellidosResponsable pasen a ser un único parámetro de tipo Persona llamado responsable
  5. Para que el paso anterior funcione es preciso eliminar la clase Persona creada anteriormente, para evitar conflictos con la nueva clase Persona creada.

Evitar código repetido en Tarea y HistoriaUsuario

  1. Generalizar Tarea y HistoriaUsuario a Item.
  2. La clase Item contiene los campos id, nombre, descripción y estado.
  3. En toString() de HistoriaUsuario extraer un método llamado estadoToString(informeEstado), que incluya todo el código dentro de switch(estado)
  4. Promover estadoToString(informeEstado) a la clase Item (para que la clase Tarea también pueda usarla).
  5. Sustituir dentro de toString de la clase Tarea la sentencia switch(estado) por el método estadoToString(informeTarea) heredado de Item

Retocar nombres en la clase Persona

Cambiar nombres de atributos y métodos en Persona (quitar el sufijo "Responsable").

Aportar semántica a los posibles estados de la clase Item

  1. Crear constantes públicas para los estados en la clase Item:
    • ESTADO_PENDIENTE = 0
    • ESTADO_EN_PROCESO = 1
    • ESTADO_EN_PRUEBAS = 2
    • ESTADO_TERMINADO = 3
  2. Cambiar en Scrum el estado de la HistoriaUsuario y las Tareas por la constante Item.ESTADO_PENDIENTE

Reorganizar las clases en paquetes

  1. Crear los paquetes siguientes:
    • net.ametsis.Scrum.ed.Scrum.modelo
    • net.ametsis.Scrum.ed.Scrum.modelo.items
  2. Mover las clases Item, Tarea e HistoriaUsuario a Nuestro.ametsis.Scrum.modelo.items
  3. Mover la clase Persona y Sprint a net.ametsis.Scrum.modelo