La copla del desacople

Cuando empiezas a aprender sobre arquitectura software, descubres muchas reglas que a veces son contradictorias. Cuando ya has aprendido patrones de diseño y patrones de análisis, entonces descubres o te enseñan cosas como que tú tienes que ser muy listo pero tu código muy tonto,  y claro, los patrones de diseño no son precisamente código tonto. ¿En qué quedamos?

Un ejemplo claro que me mantiene entretenido últimamente es la regla de alta cohesión-bajo acoplamiento. Del que se derivan otros como el de OCOR (One Class, One Responsability) o el principio Open-Close (abierto para la extensión, cerrado para la modificación). 

Este principio habla de que los diferentes componentes software han de tener una responsabilidad clara, y deben poder reemplazarse sin que afecte al resto de componentes. Este desacople, que se lleva buscando años, adquiere especial relevancia últimamente, aplicándolo al famosísimo desarrollo en tres capas: vista, negocio y datos.

Lo que se pretende es un desacople total entre estas tres capas. Esto es algo totalmente posible hoy día. Imaginad que los datos los cogemos vía un web service. Entonces, nuestra capa de negocio podría ser totalmente reemplazada, siempre y cuando la nueva, que puede estar en otro servidor, incluso en otro lenguaje de programación, utilice las mismas llamadas al web service (el mismo contrato WSDL). Y lo mismo sucede con la capa vista. Últimamente me ando debatiendo entre si hacer o no una capa vista totalmente desacoplada. Esto es algo sólo viable desde que existe ajax, y desde que el javascript se hizo adulto y el JSON emergió. El JSON es a la capa vista lo que el XML a los web services.

Gracias al JSON, podemos hacer una capa vista totalmente en Javascript, con llamadas asíncronas al servidor para traer cualquier dato que haya que pintar. Las llamadas desde la capa vista siempre devuelven los datos en formato JSON, lo que significa que los controladores del servidor (la C en el MVC que existe en todas las capas vistas bien hechas) podrían ser Java, .NET o PHP por ejemplo. Esto, a priori es genial. Desacoplamiento perfecto. Pero hacer esto es un sobredimensionamiento ¿o no? Supongo que depende de quién lo vaya a programar. Si eres más experto en JQuery que en Java, pues claro, viene bien hacer esto.

Si en tu equipo de desarrollo hay expertos en Javascript/JSON con dominio de JQuery o Prototype, te puedes permitir el lujo de hacer un diseño/arquitectura de baja fidelidad en un lenguaje tipo PHP o Grails, y si el proyecto convence, pasarlo a Java o .Net sin necesidad de tocar ni una línea de la capa vista. Esto es realmente útil, porque lo cierto, y este es otro mandamiento de la arquitectura software, es que para el usuario el interfaz es el sistema, y si ve un interfaz bonito y usable, tienes muchas papeletas para triunfar. Si tu proyecto está pendiente de aprobación o lo tiene que revisar con lupa un equipo de QA, poder prototipar la capa vista sin preocuparse demasiado por la arquitectura de la aplicación es un lujazo, cada día más necesario.  Sí, porque, ¿Cuántas veces habéis hecho unas pantallas para una demo que no ha dado tiempo a terminar, pero tiene que dar el aspecto de que está terminado y funcionando? Yo también muchas veces. Y hacer este tipo de fachadas (pantallas con funcionalidad simulada) es muy más fácil, y da un aspecto más realista cuando todo el interfaz se construye en el cliente (está desacoplado), y sólo tienes que simular las llamadas JSON.

Es así de triste pero es muy cierto: miles de aplicaciones web se venden gracias a su interfaz. Es tan absurdo como elegir un coche sólo porque su carrocería es muy elegante. Con el tiempo se aprende que una arquitectura robusta con un interfaz feo y sobre todo difícil de usar, no vende. Así que si quieres triunfar en este mundillo, más te vale aprender un poco de “capa vista”, y ponerle a tu coche una buena carrocería y un salpicadero impactante.

Todo esto es lo que me hace debatirme entre hacer una capa vista totalmente desacoplada o no. Para la capa de datos ni me lo planteo. Insisto en si me lo estoy planteando para la capa vista es porque la capa vista vende, y, repito, para el usuario/cliente lo es todo. Supongo que acabaré aplicándome la copla ésta del desacople, y lloraré cuando vea trabajar a un desarrollador de .Net, en su maravilloso IDE donde todo está integrado y la programación es casi visual.

Otro inconveniente que observo al llevarme la capa vista a JSON es que, los IDEs no están tan preparados para el Javascript como lo están para el Java, Groovy o .Net. El Javascript ha madurado muy deprisa. Lleva mucho tiempo entre nosotros, pero hasta que no empezó a comer ajax no dio el estirón. Y menudo estirón ha dado. Se le han quedado pequeños todos los IDEs. Espero que esto se resuelva rápido, porque a pesar de la existencia de joyas como Selenium para testar el interfaz y la capa vista en general, sigue habiendo un trecho que recorrer a día de hoy, a principios de 2011.

El caso amigos es que, recapitulando, hay que desacoplar correctamente las clases, los paquetes donde guardas las clases y los componentes software que usan esas clases. Desacoplar la capa vista o la capa datos es también recomendable, pero es un sobreesfuerzo que se ha de sopesar con mucho cuidado. La tecnología JSP y JSTL (dentro del mundo Java) pierden fuerza con estas nuevas tendencias… con lo que me ha costado dominarlas :-)
Sin embargo, no es ni mucho menos, la primera vez que una nueva forma de hacer las cosas triunfa por un solo detalle, a pesar de tener muchos otros en contra. A veces ese único detalle es tan crucial, que merece la pena el sobreesfuerzo. No estoy 100% seguro de que, en el caso que nos ocupa –ese detalle de tener la capa vista totalmente desacoplada– vaya a ser tan crucial. Supongo que es un poco pronto para ello, pero acabaremos haciéndolo. Sobre todo si nuevas tendencias en el desarrollo como CQRS, o el desarrollo orientado a eventos reloaded triunfan próximamente.

Otra vez, se confirma lo que siempre digo, y es que para ser un buen arquitecto software, no basta con saberse las reglas muchas veces contradictorias, sino cuando aplicar una y no su inversa.