Supervising Presenter

Este patrón permite extraer la lógica de presentación de la vista en una clase conocida como Presenter. La vista tiene alguna autonomía, y el control en la vista puede estar ligado directamente a un dominio o value objects.

Características del patrón

• El estado está en la vista
• La lógica está en el Presenter
• La entidad Presenter observa la vista
• La entidad Presenter actualiza la vista
• La entidad Presenter tiene conocimiento de la vista
• La vista no tiene conocimiento de La entidad Presenter

Una característica importante de este patrón es que la vista inconscientemente está asociada a una clase Presenter, pero esta clase Presenter tiene consciencia de la vista. Es una característica heredada de Model-View-Presenter y es la principal diferencia entre MVP y MVC. Cada Supervising Presenter debe observar su vista asociada a los eventos del usuario, coordinar los cambios con la vista necesaria y actualizar el modelo, si es necesario.

NOTAS SOBRE EL PATRÓN
Fácil de testear
La separación de la lógica en una clase a parte facilita el test. Hay un inconveniente: Supervising Presenter tiene una dependencia con la vista asociada. Para testear un patrón Supervising Presenter se necesitan instancias de las vistas actuales o mock objects que simulen el comportamiento de estas. Probablemente esto ocasione los mismos problemas que con Autonomous View.

Una mejor separación
Seguir el patrón Supervising Presenter puede ayudarnos a obtener una arquitectura con vistas separadas, pero con acoplamiento hacia éstas, debido a que la clase Presenter no sirve de nada si la vista asociada, por lo que podemos estar rompiendo uno de los pilares de la POO y de la ingeniería del software, el low coupling.

Los aspectos comunes de la presentación pueden ser refactorizados con una clase “Presenter” y esto nos ayudaría a reducir la duplicación de código y a mejorar la consistencia de la aplicación.

¿Cuánta lógica se debe extraer?
El patrón Supervising Presenter está entre el Autonomous View y el Passive View. El patrón Passive View extrae la lógica de la vista hacia la clase Presenter, incluidos los bindings. El dilema de cuanta lógica se debe extraer dependerá del proyecto entre otras cosas.

¿Mock objects?
El uso de mock objects es una estrategia común cuando se testea, pero su uso para simular vistas Flex no es una tarea trivial. Los mock objects resultantes se pueden usar en otros proyectos. La lógica se extrae pero el estado permanece en la vista.
El patrón Supervising Presenter extrae la lógica de presentación de la vista, pero deja el estado en ésta. Normalmente en el paradigma de orientación a objetos, el estado y la lógica están encapsulados en la misma clase. Esto facilita la refactorización y la reutilización.

Aplicación de ejemplo
En el siguiente enlace hay un ejemplo de este patrón.

A continuación os presento el diagrama de clases que sigue este ejemplo:

Tal como vemos en el diagrama, la vista AlbumBrowser tiene asociada una clase Presenter, AlbumBrowserPresenter. Esta clase recibe la vista con la que debe tratar a partir del constructor, además trata con los datos y los asigna a la vista. También se encarga de repercutir en la vista asociada los cambios de estos datos.
Lo mismo pasa entre la vista AlbumForm y AlbumFormPresenter.

Conclusiones sobre este patrón
Este patrón mejora el proceso de testing y ayuda a decrementar la duplicación de código de la aplicación.