Usando el patrón estrategia:
Creando el
ambiente adecuado.
Hoy en día, en
el mundo del software, vivimos un empuje muy importante de los lenguajes
orientados a objetos. Sin embargo, no es lo mismo utilizar un lenguaje
orientado a objetos, que utilizar técnicas óptimas de orientación a objetos. Por eso, es muy común encontrarnos equipos de
desarrollo que trabajan con lenguajes orientados a objetos del mismo modo en
que lo hacían con lenguajes estructurados
Los buenos
principios de orientación a objetos se reflejan en los patrones de diseño. Por
esta razón, entre arquitectos e ingenieros de software debe utilizarse el
lenguaje de los patrones, pues es la forma más segura de llegar a un producto
final de calidad.
Por eso, hemos
creado este tutorial, primero de una larga serie de tutoriales referidos a este tema, en los que pretendemos
poner ejemplos prácticos del uso de los patrones de diseño como solución
efectiva ante un problema concreto.
Planteando
un problema.
Hace ya unos
años, haciendo consultoría a una gran corporación, se planteó un problema: “Queremos cambiar el sistema actual de
autenticación de nuestra aplicación (por Base de Datos), pero no tenemos claro
aún que sistema final utilizar: LDAP o MQSeries” .
El primer
impulso de todos los programadores es lanzarnos sobre el teclado a “picar” el
código necesario para la validación en los dos tipos de sistemas finales nuevos
(cosa que habrá que hacer evidentemente), pero si antes de esto, se invierten
10 minutos más en pararse a pensar en las implicaciones que tiene cambiar el
sistema de validación en el futuro, nos ahorraremos muchos quebraderos de
cabeza y mucho tiempo (y como decía mi abuela: “el tiempo es oro”).
De todos es
sabido, que cada vez que se hace un cambio de desarrollo y hay que subir la
nueva versión de la aplicación al entorno de producción (y más en una gran
corporación), se inicia un proceso que a veces puede durar incluso meses, qué
además está sujeto a infinidad de errores y en algunos entornos puede ser
incluso un largo periodo de pánico y frustración.
¿ Sería posible que cuando en el futuro el cliente
elija cual es su sistema de validación final, nos evitásemos realizar una nueva
instalación en producción ?
La respuesta
es si, y si te interesa saber cómo, la solución es usar el patrón estrategia.
La pregunta que se plantea este patrón de diseño es la siguiente:
¿
Puede darse el caso de que el sistema que se esté construyendo tenga un
comportamiento que se desee cambiar en el futuro ?.
Desenlace.
Para la
implementación práctica de la solución al problema planteado en el patrón
estrategia, haremos uso de otros dos patrones de diseño: El patrón factoría, y
el patrón singleton.
Vamos a
empezar a desarrollar la solución. Lo primero que haremos, será crear un interface al que llamaremos IAutenticacion.java:
A continuación, crearemos las clases que realizan la
validación en los tres posibles sistemas finales que el cliente puede elegir, y
haremos que implementen las tres el interfaz:
AutenticacionBBDD.java
AutenticacionLDAP.java
AutenticacionMQ.java
En esta situación, si no hiciésemos caso de nuestro patrón
estrategia, lo que haríamos sería que en nuestro código de validación, haríamos
algo similar a esto:
–
Si estamos validando por MQ:
AutenticacionMQ mq = new AutenticacionMQ();
mq.autentica(login,clave);
–
Si estamos validando por LDAP:
AutenticacionLDAP ldap = new AutenticacionLDAP();
ldap.autentica(login,clave);
–
Si estamos validando en BBDD:
AutenticacionBBDD bbdd = new AutenticacionBBDD();
bbdd.autentica(login,clave);
Cada vez que se cambie la forma de validarse, tendremos que
hacer un pase a producción con la modificación adecuada en cada caso.
Vamos sin embargo a hacerlo siguiendo el patrón estrategia. Creemos una
clase que implemente el patrón de diseño Factoria de
Objetos. La llamaremos FactoriaAutenticacion.java:
En la clase, hemos creado un método que crea un objeto del
tipo deseado, en función de una entrada en un fichero de propiedades.
Además, las factoría interesa que sea singleton (que sólo haya una
instancia de ellas en la aplicación). Para ello, modificaremos nuestra clase de
la siguiente manera:
Una vez en este punto, tan sólo debemos cambiar el código en
el que queremos validar (mostrados anteriormente) por este otro:
Ahora, cuando se cambie la forma de validación, tan solo
debemos cambiar la clase que usaremos para validar en el fichero de propiedades
mencionado anteriormente, sin la necesidad de realizar un pase nuevo a
producción:
# Si es por BBDD
clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionBBDD
# Si es por LDAP
clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionLDAP
# Si es por MQ Series
clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionMQ
Conclusión:
A veces un pequeño análisis
inicial, nos permite ahorrarnos muchos disgustos futuros, donde disgustos
aglutina tiempo, dinero, esfuerzo y dolores de cabeza. Si necesitas ahorrarte
disgustos, podemos ayudarte: http://www.autentia.com
