 |
| Imagen tomada de www.xprogramming.com |
Supongamos que tenemos una lista de números enteros, y queremos separarlos en dos grupos: Aquellos que cumplen una condición (C) y otros que no cumplen dicha condición (!C). Por ejemplo discriminar de entre todos los numeros de nuestra lista, aquellos que son pares. Lo más inmediato y rápido sin duda sería codificar "a fuego" un algoritmo que recorra la lista y compruebe para cada uno si la condición de la que hablamos se cumple. Éso está bien. Al fin y al cabo, funciona, lo hemos probado muchas veces.
if (numero % 2 == 0)
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
Pero... ¿Qué pasaría si mañana nos vemos en la obligación de cambiar ese filtro? Imaginemos que mañana no nos interesan los pares sino todos los positivos. Efectivamente, nos vemos obligados a acceder a las tripas del algoritmo, y cambiar un par de cosas para adaptar nuestro código a los requerimientos externos. (Bastante sencillo en éste caso, pero podría no serlo).
Ya de mano, debería preocuparnos el hecho de deshacernos de ése código pero el verdadero problema no está ahí. El supuesto mortal es ¿Y si necesitara filtrar esos números en función de lo que esta pasando?¿Y si necesitara cambiar ese filtro en tiempo de ejecución? A éstas alturas, ya deberíamos saber que es
Además ¿Y si hubiera veinte posibles condiciones?¿Tendríamos veinte bloques IF anidados?¿O un switch enorme? Esa lógica condicional es veneno puro para el mantenimiento y para el rendimiento.
Es en éste punto concreto donde debería saltarnos una alarma dentro, que nos diga "Estoy borrando algo perfectamente funcional, pero hoy ya no me sirve por requerimientos externos". Estamos tirando horas de trabajo a la basura. Es aquí donde deberíamos pensar en la palabra "Delegación".
¿Qué es la delegación?
Delegar es dejar cierta "responsabilidad" en manos de "otro". No es inmediato darse cuenta de cómo encaja la delegación en nuestro proyecto pero ahora veremos una manera mucho mas potente de lidiar con ésta clase de temas.
¿Como encaja eso aquí?
Pongamos algún concepto más avanzado sobre la mesa. ¿Qué tienen en común todos nuestros cambios en el código? Pues que consisten en alterar la condición de filtrado. ¿Que tienen en común todas nuestras condiciones de filtrado? Que evalúan un entero, y que son de carácter booleano. ¿Podríamos decir entonces que una condición en general es algo que tiene un método booleano y un entero de entrada? Pues sí. A eso se le llama TIPO en términos de orientación a objetos, y una de las maneras más potentes de representarlo es mediante Herencia. Pero no cualquier tipo de herencia.
Crearemos una Interfaz llamada "Condicion", que tendra un método
public interface Condicion {
public boolean validar(int numero);
}
public boolean validar(int numero);
}
Así definimos nuestro tipo <>. Y delegamos en sus hijos la decisión de si un numero nos sirve o no¿Que pasa ahora? Una interfaz por si sola no tiene implementación alguna de cómo validar. Pero permite a nuestro código sustituir nuestra condición grabada a fuego:
for (Integer numero : numeros){
if (numero % 2 == 0)
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
}
Por algo como ésto:
Condicion condicion = .........................;
for (Integer numero : numeros){
if (condicion.validar(numero))
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
imprime("El numero " + numero + " es par);
else
imprime("El numero " + numero + " no es par);
}
¿Que?¿No parece haber cambiado mucho no? Además ¿Donde especificamos nuestra condición? Esto es una M...
Demos el último paso. Para filtrar los números de la lista, crearemos dos implementaciones de nuestra condición abstracta que se llamarán por ejemplo "CondicionPositivo", y "CondicionPar":
public class CondicionPositivo implements Condicion {}
y
public class CondicionPar implements Condicion {}
En seguida el compilador nos obligará a punta de pistola a implementar nuestro método "public boolean validar(int)" en nuestras recién creadas implementaciones. Ahí pondremos nuestras dos formas de filtrar.
Volviendo al código anterior, vemos unos puntos suspensivos que parecen "susceptibles de no compilar bien". Ahí es donde debemos crear una instancia de nuestra clase CondicionPositivo.
Condicion condicion = new CondicionPositivo();
Nuestro código ya funciona. Ahora, ¿qué tendríamos que hacer si mañana nos interesan los números pares en lugar de los positivos? Simplemente tendremos que cambiar la linea anterior a nuestro antojo. Así, el hecho de sustituir una por otra, no es destructiva, y con el tiempo vamos alimentando nuestros recursos de código. Es decir, nuestro árbol de Condiciones crece, y podría sernos útil más adelante.
Ésto esta muy bien, pero dónde está el verdadero potencial de lo que acabamos de construir?
Sencillo. En nuestro nuevo código nada nos impide sustituir la condición en tiempo de ejecución. Es más, podríamos dejar que la condición dependiera de las acciones del usuario, y en función de qué tecla pulse, la condición varíe. Además, aún teniendo un alto número de condiciones, nuestro código permanecería impecable. Nada de lógica condicional.
Dicho todo ésto,
¿Sabrías crear un filtro para múltiplos de un numero dado (p.ej: múltiplos de 3)?
Descargate el proyecto de eclipse aquí
Un saludo!
