En el
último post os intenté convencer de que habíamos conseguido no violar el principio de inversión de dependencias con nuestra clase
Banco. Si no lo recordáis, nos quedó algo como esto:
José Luis Barrera me sugirió en los comentarios que utilizáramos una clase
Credenciales que agrupara tanto el nombre del usuario como el
Pin. Con esa nueva abstracción, el código de
Banco queda aún más claro:
Guay :D
Ahora bien, ¿qué ocurre cuando la validación de las
Credenciales falla? Tal y como tenemos ahora mismo
nuestra implementación,
OperacionesBancarias lanzaría una excepción por cada tipo de error que se produzca al validar el usuario. Por ejemplo, si lo que falla es que las
Credenciales son incorrectas se produce una excepción
CredencialesIncorrectas. Si lo que sucede es que la validación de las
Credenciales ha sido fallida más de tres veces, la excepción que se lanza es una
AccesoInvalidadoPorMultiplesReintentosFallidos. Si lo que se produce es un error en el acceso al banco real, se lanzará un
BancoInaccesible.
Veamos como implementaríamos un cliente de
Banco (un
Cajero) que se preocupe del resultado de la validación:
Pues no parece que sea muy legible... No se vosotros, pero yo estoy bastante acostumbrado a este tipo de código y tengo que decir
¡basta ya!
Las excepciones que captura
Cajero no son parte de la abstracción de
Banco, son detalles de bajo nivel que se encuentran en
OperacionesBancariasBancoManolito, con lo que estamos volviendo a violar el principio de inversión de dependencias. Además, estamos controlando el flujo del programa mediante excepciones. ¡Que desastre!
Las excepciones deberían ser para casos excepcionales
Como bien nos contó (recordó) Enrique Comba en el curso de T.D.D., las excepciones deben ser excepcionales. No tiene sentido usarlas para controlar el flujo porque, en ese caso, dejan de ser excepcionales. Esto que parece tan trivial es una de las cosas que más nos cuesta cuando nos ponemos a programar.
Con esto en mente, volvamos a nuestro ejemplo, ¿Es excepcional que unas
Credenciales sean incorrectas? ¿Es excepcional que un
Banco tenga que anular una tarjeta porque el usuario se ha equivocado n veces al intentar usarla? De nuestro ejemplo, el único caso "excepcional" puede ser que el banco real no esté accesible pero ¿de verdad es tan raro que haya un corte de comunicaciones? Para mi, ninguno de estos casos es merecedor de una excepción, así que vamos a intentar arreglarlo. Lo primero que vamos a hacer es que
Cajero no dependa de los detalles de
OperacionesBancariasBancoManolito (y si de paso evitamos controlar el flujo con excepciones, mejor que mejor). Para ello, vamos a pasarle al
Banco la responsabilidad de avisar al
Cajero cuando suceda un evento de validación (correcta, incorrecta, invalida, sin conexión). Refatorizamos nuestro
Banco para que quede como sigue:
y nuestro
Cajero ahora queda mucho más limpio:
Aunque nuestra clase
Cajero ha quedado mucho más clara, hemos pasado el problema de las excepciones a la clase
Banco. Además, estamos violando el principio de segregación de interfaces (
I). Vayamos paso a paso.
Segregación de interfaces
Clients should not be forced to depend upon interfaces that they do not use.
Los clientes no deben verse forzados a depender de interfaces que no usan.
Para cumplir este principio, nuestra clase
Cajero debe implementar un interfaz para manejar los eventos de validación, que es lo único que la clase
Banco necesita conocer de
Cajero:
Y nuestra clase
Banco dejaría de depender de
Cajero para depender de dicho interfaz:
Ahora que nuestra clase
Cajero ya cumple el principio de segregación de interfaces, arreglemos
Banco.
La solución que se me ha ocurrido es que sea la abstracción
Token la que nos de la información que actualmente nos dan las excepciones:
Ahora el flujo ya no es guiado por excepciones pero, lo que me parece más importante aún, es que nuestro código ahora es más sencillo de extender. Antes necesitábamos ir a un javadoc (o similar) para leer que tipo de excepciones eran necesarias para que
Banco funcionara, ahora basta con implementar
Token.
Por último, tengo que decir que no me gustan las estructuras if-elseif-elseif-else, pero para este caso en particular no me parece tan horrible. Si los motivos por los que
Token puede no ser válido fueran más o pudieran cambiar más a menudo me pensaría una solución con suscriptores similar a la que hemos utilizado con el
Cajero. Si os apetece hacerlo os lo dejo como ejercicio :P
Perdonad que me haya quedado una entrada tan larga y atolondrada. Espero que al menos se entienda lo que he intentado expresar :D ¡Nos vemos en la siguiente!
Nota: No haría estas refactorizaciones que he hecho aquí si no tuviera una buena base de pruebas contra las que probar cada pasito.
