Refactoring en Español (2)

Palabras clave:
Tiempo aproximado: 2 min.
En esta nueva entrega sobre refactorizar, basada en el ejemplo del primer capítulo de “Refactoring“, vamos a ver el apartado “Moving the Amount Calculation”, donde Fowler nos enseña cómo cambiar el diseño y llevar código de una clase a otra.

Moving the Amount Calculation

Como el método Customer.amountFor (el que hemos creado como consecuencia del refactor de la entrega anterior) usa datos de Rental pero no de Customer, parece que es mejor moverlo a Rental.

Para ello seguimos los siguientes pasos:

1. Si usamos Eclipse, colocamos el cursor sobre el nombre del método y hacemos botón derecho + Refactor / Move. En el diálogo que nos muestra Eclipse:
* Seleccionamos la clase Rental
* Marcamos para que el método actual delegue en el nuevo y que quede marcado como @deprecated
* Podemos ver con Preview cómo van a quedar

2. Ejecutamos los tests para comprobar que los cambios no han estropeado nada.

3. Renombramos el método a Rental.getCharge (y ponemos el javadoc correspondiente). Para renombrar un método, Eclipse proporciona varios caminos: Alt+Shift+ R (el camino corto), Alt+Shift+T + Rename (el camino intermedio) y botón derecho + Refactor + Rename (el camino largo). La ventaja de usar Eclipse para renombrar métodos es que nos va a cambiar el método no sólo en la clase que estamos editando sino también en todas aquellas clases que usen el método (las tengamos abiertas para editar o no).

Hago hincapié en que debemos escribir el javadoc de Rental.getCharge porque cuando cambiamos un método de clase normalmente estamos cambiando la intención del mismo y debemos comunicar esto a los usuarios del método. Para comunicar el cambio usamos normalmente el nombre del método pero no podemos olvidar el comentario javadoc porque puede introducir errores de interpretación si nos dejamos llevar y no los actualizamos (no sólo incluyendo los @deprecated, y cambiando los @param donde toque sino cambiando el texto que explica el comportamiento de los métodos).

4. Volvemos a ejecutar los tests.

A continuación comprobamos que podemos eliminar el método “viejo” (que hemos marcado como @deprecated). (Fowler comenta que en ocasiones podemos preferir dejar el método “viejo” como un delegado al “nuevo” porque, por ejemplo, forme parte de la interfaz pública de la clase).

5. Comprobamos que el método Rental.getCharge sólo es llamado desde Customer.amountFor
y éste sólo desde Customer.statement (con Ctr+Alt+H).

6. Sustituimos la llamada en Customer.statement directamente a Rental.getCharge
thisAmount = each.getCharge();

7. TESTS

8. Comprobamos que Customer.amountFor ya no se usa (con Ctr+Alt+H de nuevo) y lo eliminamos (sin miedo)

9. TESTS

Fowler llama “Move Method” a la refactorización de código que consiste en mover un método de una clase a otra y es el primero de los que propone en el capítulo 7 : “Moving Features Between Objects”. Ahí se explican tanto las motivaciones que nos deberían llevar a realizar este cambio como los pasos a seguir para realizarlo de manera mecánica.

Fowler propone “Replace Temp with Query” en statement para sustituir las ocurrencias
de thisAmount por each.getCharge. (Yo no lo voy a implementar aún).

Recordatorio:

Que no se me olvide, en la entrada anterior “Refactoring en Español (1)” tenéis los enlaces al código con los tests y el código “copi-pegado” del libro.