El patrón Observer (Observador)

Que no, que no se me ha olvidado que tengo un blog que mantener. Lo que pasa es que uno tiene muchas ocupaciones e historias variass y no puede atender a todo, jejeje. Pero ya estoy aquí de nuevo, y para añadir una nueva entrada, esta vez sobre informática que la tenía muy abandonada (y mi amigo Longi decía que ya no le escribía nada, así que esta entrada va para él).

Siguiendo con mi afición por la Ingeniería del Software y mi afán por las buenas prácticas de la programación, vuelvo a hablar sobre un patrón de diseño. Esta vez el patrón en cuestión es el llamado patrón Observador.

Bien es sabido por todos los entendidos en Ingeniería del Software, que las capas de dominio o negocio (en MVC el modelo) nunca deben conocer a las capas de presentación (en MVC la vista). Con esta medida básica se evita bastante acoplamiento en los sistemas desarrollados. Sin embargo, en ocasiones es necesario que la capa de dominio notifique a la capa de presentación un cambio de estado en el sistema. Puesto que ya hemos dicho que la capa de dominio de tocar a la capa de presentación, pupa no se hace, vamos a necesitar un intermediario, que vaya que casualidad va a ser la propia clase de presentación, eso sí, con un truco del almendruco. El truco es utilizar una interfaz llamada Observador, que será a la que realmente  accederá la clase de Dominio. La clase de dominio utilizará al Observador para notificar a la clase de presentación el cambio de estado. En el siguiente diagrama de clases se puede ver el diseño de una arquitectura que utiliza el patrón Observador.

Como se puede ver, las clases de presentación implementan la interfaz Observador y el método notificar que esta interfaz define. La clase de dominio tendrá una lista de Observadores que utilizará cuando tenga que notificar un cambio de estado.

Un sistema en el que puede ser útil este patrón es aquel que implementa un programa de gestión de entradas para eventos deportivos. Las entradas pueden ser compradas por móvil, desde la web o desde un terminal de venta situado en una taquilla. Desde cada aplicación podrá verse en todo  momento los asientos libres. Si desde una aplicación móvil se reservase en un momento dado un asiento para un evento, el resto de aplicaciones (otras móviles, web o de escritorio) que estuvieran corriendo y mostrando información a otros usuarios deberían ser notificados y actualizar el estado de asientos libres. Con el patrón Observador esto sería posible.

El estado de las reservas de entradas estaría almacenado en un servidor. Este servidor tendría en todo momento una lista almacenada de Observadores. Cada observador sería una aplicación móvil, web o de escritorio que estuviera conectada al servidor en ese mismo momento. Cuando una de estas aplicaciones reservara una entrada para un evento, el servidor actualizaría todos sus observadores, por medio de sus respectivos métodos notificar. Así la aplicación móvil actualizaría la pantallita del dispositivo en cuestión, la aplicación web actualizaría un tabla, y la aplicación de escritorio actualizaría por ejemplo un listbox.

Con el patrón Observador, se eliminan también esperas activas, realizando las notificaciones por interrupción ya que las llamadas se hacen mediante callbacks.

Para esta entrada no he preparado código. Aún así en el enlace de Wikipedia que he añadido anteriormente podréis ver ejemplos.

Ante diversas dudas que podáis tener, no dudéis en dejar vuestros comentarios.

Saludos y hasta la próxima.