Refactorings para cumplir “Tell Don’t Ask”

“Tell, Don’t Ask” (TDA) es el principio que nos permite tener Parameter Objects inteligentes y eliminan la rigidez en nuestros algoritmos. Recuerde que asumimos que se ha seguido los pasos de Algoritmos Mantenibles hasta el paso 4 antes de este.

Recordemos que el principio TDA nos da dos indicaciones:

  • No haga lo que el objeto mismo puede hacer. Si alguna operación se realiza con propiedades del Parameter Object entonces no deberíamos pedirle las propiedades, sino que él nos debería dar lo que buscamos.
  • No pida al objeto su tipo para tomar decisiones por él. Por “tipo” nos referimos a propiedades booleanas o enumerados.

A continuación, listo los pasos y algunas recomendaciones:

1. Buscamos los sitios donde aplicar el principio, e indicamos una marca para refactorizarlos (un comentario “TO DO”):

a. Una línea en donde no se cumpla la Ley de Demeter porque introdujimos el Parameter Object.

cumpla-la-ley-de-demeter

b. Una línea en donde haya más de una operación ya que introdujimos el Parameter Object.

mas-de-una-operacion

c. Los if o switch en donde se tome una decisión con base en una propiedad del Parameter object que sea booleana o enumerado.

no-pida-al-objeto-su-tipo

2. Cree la propiedad de solo lectura

Para cada uno de los sitios identificados crearemos una propiedad de solo lectura dentro del Parameter object. El nombre de la propiedad lo da el nombre de la función en donde se encuentre el código marcado, o la variable donde se asigne el resultado de dicha operación.

propiedad-de-solo-lectura

3. Corte y pegue el código identificado con el “TO DO”.

copie-el-codigo-to-do

4. Logre que el código compile.

Dentro de la nueva propiedad Siempre hay que eliminar el llamado al Parameter Object (Por ejemplo, losDatos.FechaDeVencimiento se convierte solamente en FechaDeVencimiento).

propiedad-terminada

En caso de que dentro de dicho código se enviara el Parameter Object a otro objeto, como en este ejemplo,

this-antes

… enviaremos ahora “this”, lo que significa que el objeto se envía a sí mismo. Este es un ejemplo:

this-despues

5. Asegúrese que las pruebas unitarias son exitosas.

Si no compilan, las debemos ajustar. Si fallan es porque hemos cometido algún error al realizar el refactoring. No debemos modificar las pruebas, sino el código refactorizado.

Recomendaciones adicionales

Recuerde eliminar los comentarios innecesarios para que el código no confunda a sus lectores.

En caso de que debido al refactoring alguna clase quede sin lógica alguna, la podemos eliminar. Por ejemplo, podemos borrar la siguiente clase pues todo lo que hace es retornar  la propiedad del parameter object:

clase-innecesaria-se-puede-borrar

… las pruebas unitarias se modifican para usar “losDatos.Impuesto” en vez de llamar al método “GenereElImpuesto”. Recuerde ajustar los nombres de la clase y de los métodos de prueba.

pruebas-unitarias-usan-parameter-object

Notemos cómo el código orientado a objetos es más conciso y fácil de entender luego de refactorizarlo. Estamos preparando el código para que a futuro nosotros u otros colegas puedan ser más eficientes al hacer cambios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s