Patrones de diseño y la programación artística

No soy un analista, si acaso más bien un analista/programador. ¿Diferencias? El tamaño de los sistemas de información a los que me puedo enfrentar (aunque el arquitecto creo que no es un analista, estas cosas se suelen confundir).

Llevo programando muchos años, así que tengo cierta experiencia en programación estructurada (imperativa), y algo menos en orientada a objetos (no es habitual encontrar problemas que se resuelvan empleando este paradigma).

Esto me lleva a planificar los proyectos y a desarrollar de forma más o menos modular. A estas alturas una de mis obsesiones es maximizar el código reutilizable, pero reconozco que tengo limitaciones. Una de ellas: cero en arquitectura de software.

Ni siquiera llegué cursar la asignatura, así que solo sé lo que es por haber leído cosas por mi cuenta, y algunas son poco esclarecedoras (menos mal que la versión en inglés está mejor).

Bueno, resumamos mucho: la arquitectura del software es un conjunto abstracto de patrones que nos pueden guiar en diseño de grandes sistemas. Vamos, aplicaciones importantes (no he hecho nunca ninguna).

No quiero profundizar más en el tema de la arquitectura, sino más bien echarle un ojo a un patrón de diseño que está al alcance de cualquiera (al menos en cuanto a comprenderlo, creo). La criatura se llama Modelo Vista Controlador (MVC, en inglés Model View Controler).

El concepto es fácil de coger. Definimos una arquitectura de tres capas: Modelo, Vista y Controlador (ahora que alguien me diga que no se veía venir :D).

Vamos a describir un poco cada parte:

• Modelo: se trata de las estructuras de datos, los datos propiamente dichos y la lógica de la aplicación (procesos que afectan a los datos). Podríamos decir que es cómo funciona la aplicación.
• Vista: es la interfaz que ve el usuario. Dependiendo de la implementación, esta interfaz se genera en base a los datos que se obtienen directamente del modelo o con la información que proporciona el controlador. Podríamos decir que es la visualización del modelo.
• Controlador: es la capa que se encarga de procesar los eventos. En base a lo que indica el usuario, produce modificaciones en el modelo (y por consiguiente en la vista). Podríamos decir que es la traducción de las acciones del usuario en cambios de estado del modelo.

Posible representación de MVC

Ahora veamos en qué forma puede esta arquitectura facilitar mi trabajo, realizando aplicaciones web principalmente.

Las aplicaciones basadas en web son especialmente complejas por el formato de la plataforma y por la estructura de pregunta / respuesta. A poco que nos paremos a pensar veremos cierta relación entre una aplicación web y algunas de las capas del patrón: la vista es la web que ve el usuario en su navegador, el controlador es el código que interpreta el formulario o la petición del navegador y lo traduce a una llamada a una función del modelo, para finalmente devolver una vista (página web).

Pues cualquiera que haya hecho una aplicación web sabrá que esto no se suele hacer así ;), probablemente por los vicios que se adquieren cuando se emplean lenguajes como PHP, que permiten con demasiada facilidad mezclar las tres capas (código dentro del HTML, HTML dentro del código, con llamadas a la base de datos por todas partes :D).

La consecuencia de esta mezcla es que resulta muy complicado mantener las aplicaciones, reutilizar código es una pesadilla (hacer copy & paste no cuenta como reutilizar código :D), y cada proyecto acaba siendo un nuevo Frankenstein en nuestra cuenta particular.

Las ventajas que obtenemos aplicando la arquitectura MVC son significativas, sobretodo trabajando con la plataforma web. Como ya he comentado, siempre tendremos una llamada al controlador (petición del navegador), que accederá al modelo y devolverá una vista (página web).

Las arquitectura de este estilo prometen siempre los mismo: independencia de las capas. Lo que a su vez nos lleva a... ¡reutilizar código!

Obviamente al modelo se reutilizará solo cuando se trate de la misma aplicación, aunque cambiando vistas e incluso el controlador también puede tener sentido (por ejemplo, si empleamos pegamento como xml-rpc o soap, podríamos hacer una vista + controlador que no fuera web).

El controlador lo podremos reutilizar con toda seguridad. El controlador de un listado en forma tabular será siempre el mismo (ordenar por columna, mostrar siguiente o anterior página, etc), ya que la parte de mostrar la información recaerá en una vista y las modificaciones de los datos sobre el modelo.

Por último las vistas serán como lo que es CSS a HTML: con los mismos datos, elegiremos la representación que más nos interese (por ejemplo interesante cuando se desea generar un PDF, sería otra vista).

Vamos, que la idea me ha convencido bastante. Voy a intentar consumir toda la literatura que pueda este verano para poner en práctica esta arquitectura cuando llegue el momento. Para ir abriendo boca: The Model-View-Controller (MVC) Design Pattern for PHP de Tony Marston (ojo al resto de la web, que este tío es impresionante).