Capítulo 23: presentadores y objetos humildes - Clean Architecture

En el capítulo anterior se introdujo el concepto de presentador. Los presentadores son una forma de patrón «Humble Object» el cual nos ayuda a identificar y proteger los límites arquitectónicos. 

El patrón «Humble Object»

El patrón «Humble Object» es un patrón de diseño que se identificó originalmente como una manera de ayudar a las pruebas unitarias para separar los comportamientos que eran difíciles de probar frente a los que eran fáciles. La idea era muy simple: separar el comportamiento en dos módulos o clases. Uno de esos módulos es simple, contiene todos los comportamientos que son difíciles de probar despojados de su esencia más simple. El otro módulo tiene todos los elementos comprobables que fueron despojados del objeto humilde. 

Por ejemplo, las GUI son más difíciles de probardado que es más difícil escribir pruebas que vean la pantalla y comprueben que los elementos apropiados se muestran. Sin embargo, el comportamiento de una GUI es, en realidad, fácil de testear. Usando el patrón «Humble Object» se pueden separar estos dos tipos de comportamiento en dos clases diferentes llamadas «Presenter» y «View».

Presentadores y vistas

La vista es el objeto humilde que es difícil de probar. El código en este objeto se guarda tan sencillo como se pueda. Este mueve los datos a la GUI pero no procesa los datos.

El presentador es el objeto para probar. Su trabajo es aceptar los datos desde la aplicación y formatear estos para la presentación de manera que la vista pueda moverlos a la pantalla simplemente. Por ejemplo, si la aplicación quiere que se muestre una fecha en un campo esta le entregará un objeto «Date» al presentador. El presentador formateará la fecha en una cadena apropiada y colocará esta en una estructura de datos simple llamada «View model» donde la vista puede encontrarlo.

Si la aplicación quiere mostrar dinero en la pantalla, este podría pasar un objeto «Currency» al presentador. El presentador formateará ese objeto con los decimales apropiados y el símbolo de moneda, creando una cadena la cual puede colocarse en el modelo vista. Si el valor de la moneda es negativo entonces debería mostrarse en rojo por lo que se puede enviar un simple flag en el modelo vista.

Cada botón en la pantalla tendrá un nombre. Ese nombre será una cadena en el modelo vista colocado allí por el presentador. Si esos botones tienen que estar en gris el presentador asignará un flag apropiado en el modelo vista. Cada nombre de los item del menú es una cadena en el «Model View», cargada por el presentador.

Los nombres para cada «radio button», «checkbox» y campo de texto se cargan por el presentador, cadenas y booleano apropiados en el «ViewModel». Las tablas con números que se deberían mostrar en la pantalla se cargan, por el presentador, en tablas con cadenas que se propiamente formateadas por el «View Model».

Todo lo que aparece en pantalla y que la aplicación tenga algún tipo de control sobre la pantalla se representa en la vista del modelo como una cadena, un booleano o un enumerado. La vista sólo tiene el propósito que cargar los datos del modelo de la vista en la pantalla. De esta manera se consigue que la vista sea humilde.

Test y arquitectura

La comprobabilidad es un buen atributo de una buena arquitectura. El patrón «Humble object» es un buen ejemplo porque la separación de los comportamientos en partes comprobables y no comprobables a veces definen los límites de la arquitectura. El límite de presentador/vista es uno d e estos límites aunque hay muchos otros.

Test y arquitectura

La comprobabilidad es un buen atributo de una buena arquitectura. El patrón «Humble object» es un buen ejemplo porque la separación de los comportamientos en partes comprobables y no comprobables a veces definen los límites de la arquitectura. El límite de presentador/vista es uno de estos límites entre muchos otros.

Entradas a la base de datos

Entre los interactuadores de los casos de uso y la base de datos están las entradas a la base de datos. Estas entradas son interfaces polimórficas que contienen métodos para crear, actualizar, leer o borrar una operación que puede realizar la aplicación en la base de datos. Por ejemplo, si la aplicación necesita saber los últimos nombres de todos los usuarios quienes iniciaron sesión ayer entonces la interfaz «UserGateway» tendrá un método llamado «getLastNamesOfUsersWhoLoggedInAfter» que toma un «Date» como su argumento y devuelve una lista de los últimos nombres.

Hay que recordar que no se permite SQL en los casos de uso, en vez de eso se usan las interfaces de entrada a la base de datos que tienen los métodos apropiados.Esas entradas a la base de datos están implementadas por las clases en la capa de base de datos. Esta implementación es el «humble object». Este simplemente usa SQL o cualquier interface a la base de datos para acceder a los datos requeridos por cada uno de los métodos. Los interactuadores, en contraste, no son humildes porque ellos encapsulan las reglas de negocio específico. Aunque ellos no son humildes, aquellos interactuadores son testeables porque las entradas se pueden reemplazar con «stubs» y «test-doubles» apropiados.

Mapeadores de datos

Regresando al tema de las bases de datos, ¿a que capa pertenece los ORMs como Hibernate?

Primero hay que aclarar algo: no existen un objeto relacional mapeador (ORM). La razón es simple: los objetos no son estructuras de datos. Al menos ellos no son estructuras de datos desde el punto de vista de sus usuarios. Los usuarios de estos objetos no pueden ver los datos desde que estos son privados. Aquellos usuarios ven solo los métodos públicos de ese objeto. Así que, desde el punto de vista de un usuario, un objeto es simplemente un conjunto de operaciones.

Por el contrario una estructura de datos es un conjunto de variables públicas que no tienen un comportamiento. Los ORMs estarían mejor nombrados como “data mappers” porque ellos cargan datos en estructuras de datos desde las bases de datos relacionales.

¿Dónde deberían residir los sistemas ORM? En la capa de la base de datos, por supuesto. De hecho, los formularios ORMs  son otro tipo de límite «Humble Object» entre las interfaces de entrada y las bases de datos.

Escuchadores de servicios   

¿Qué hay sobre los servicios? Si tu aplicación se debe comunicar con otros servicios o si tu aplicación provee un conjunto de servicios, ¿encontraremos en el patrón «Humble Object» un límite de servicio? 

Por supuesto, la aplicación cargará datos en estructuras de datos simples y

entonces pasa estas estructuras a través de los límites a módulos que propiamente formatean los datos y los envían a servicios externos. En la parte de la entrada, los escuchadores de servicio recibirán datos desde la interfaz de servicio y formatean estos en estructuras de datos simples que se pueden usar en la aplicación. Las estructuras de datos se pasa a través de los límites de servicio.

Conclusión

En cada límite arquitectural, podemos encontrar probablemente el patrón “Humble Object” acechando en algún lugar cercano. La comunicación a través de los límites casi siempre involucra algún tipo de estructuras de datos simple y el límite frecuentemente dividirá algo que es complicado de comprobar en algo que es fácil de comprobar. El uso de este patrón en los límites arquitectónicos incrementa bastamente la comprobabilidad del sistema entero.