Swift: CleanCode con principios SOLID

Desde que empecé a trabajar profesionalmente como programador, he recibido muchas entrevistas de empresas grandes, pequeñas, consultoras y reclutadores. Todas las formas de selección en algún punto han tenido en común la típica pregunta: «¿Conoces los principios SOLID?», «¿Estás familiarizado con metodologías de trabajo Clean Code y principios SOLID?»

Cuando empiezas a buscar información sobre los principios SOLID, por lo general todos derivan de las mismas fuentes y la misma idea. Y para no repetir el mismo esquema que se usa en la mayoría de las explicaciones, te proporcionaré un enlace a la wiki y al artículo original.

Tampoco voy a convertir esto en un manual más explicando los principios de Clean Code, repitiendo los mismos esquemas de siempre, etc. Como he hecho anteriormente, te facilitaré el enlace al artículo original.

Después de estos años programando en iOS, he tenido la oportunidad de participar en proyectos de empresas del IBEX 35. Dada esta experiencia, sí quiero compartir la idea simplificada que se sigue por lo general en estos proyectos. Claro está que cada uno tiene sus particularidades, pero todos derivan de esta base.

Siento ser así de cruel, pero vamos a empezar con un esquema de las capas básicas. Da igual a qué lenguaje de programación te dediques, en principio, debería poder replicarse a rasgos generales.

Con el siguiente esquema, mostramos las capas en las que vamos a tratar y obtener los datos.

Tenemos dos formas de ver este esquema y hacerlo entendible. A mí, personalmente me parece más sencillo si lo vemos de derecha a izquierda y normalmente es la forma en la que se construye la lógica que asocia la vista o el conjunto de vistas. Si lo vemos de derecha a izquierda, digamos que son los procesos en los que pasa la lógica para obtener el contenido de una vista, pasando por los cimientos. Si lo vemos de izquierda a derecha es como ver una casa desde fuera y te vas acercando hasta ver el contenido de dentro. Empecemos con dos conceptos básicos: DO y DTO.

• DTO: Si hablamos en términos de Bases de Datos, las siglas significan Data Transfer Object. En seguridad informática significan Denial of To Operate. Y el que nos interesa en principio a la mayoría que entra al artículo es Data Transport Object. Fuera de su significado en siglas, son todas las estructuras de datos con sus parámetros tal y como las almacenamos o recogemos del servicio.

• DTO/Entidad: Objeto de Transferencia de Datos/Entidad. Normalmente, tenemos tantas entidades como DTOs, pero su contenido puede no ser exactamente el mismo. Con la Entidad, damos forma a los datos de la manera en que queremos mostrarlos o manipularlos.

Por ejemplo, una práctica muy común en la programación es que cuando queremos recibir información de un servicio externo en formato Int, Doubles, Float, etc., la recibimos como Strings. Normalmente, al convertir un DTO a una Entidad, lo pasamos convertido al tipo de dato que queremos manejar durante la aplicación. Esto tiene una clara ventaja. Imaginemos que, por el motivo que sea, recibimos un Double como String y con el tiempo ese Double pasa a ser Int. Al cambiar únicamente ese conversor, nos evitamos refactorizar gran parte del proyecto.

Pero las posibilidades de esto no solo está en la conversión de datos, si no en muchas más cosas que facilitan el trabajo del programador y hacen el código más ordenado y entendible. Por ejemplo, cálculos matemáticos en valores finales, manejo de fechas, crear parámetros más accesibles a la información detallada y un sin fin de posibilidades. Dicho de otro modo, una Entidad debe tener toda la información de la forma que te sea más útil.

• DataSource: En esta capa tendremos los métodos necesarios para la recopilación, escritura y modificación de los datos. Por lo general, se divide en servicios, como servicios REST, base de datos local, almacenamiento en caché, etc. Como mencionamos anteriormente, el tratamiento de datos en este nivel se realiza utilizando DTO, es decir, se envían los datos en la forma en que se guardarán o recopilarán.

• Repository: En esta capa, llamaremos tantos DataSources como necesitemos para recoger o escribir esa información. Veámoslo con un ejemplo:

Imaginemos que nuestra aplicación tiene que tener como preferencia mostrar la información de la base de datos local y, en caso de no tenerla, queremos ver si podemos obtenerla de la red. Sería en esta capa donde haríamos estas comprobaciones.

La información devuelta por Repository, al no ser tratada a nivel de escritura, lectura o modificación, debe ser devuelta como entidad a las capas superiores.

• Use Case: En algunas ocasiones lo he podido ver como Interactor. Básicamente, se encarga de realizar la lógica de la información, como el filtrado de datos innecesarios para el usuario y obtener los datos según los requisitos descritos.

En esta capa llamaremos a tantos Repository como sea necesario. A veces la información final requiere de distintos medios para ser recogida o tratada. Es en esta capa donde haremos esta lógica.

• ViewModel: En esta capa, me gusta verla como la capa «comodín». La razón es muy sencilla. Esta capa es la que comunica la vista principal con los casos de uso. Esto quiere decir que la poca lógica que debe contener debe tratarse sobre la interactividad humana o del ciclo de vida de la vista. Por ejemplo:

El usuario tiene una pantalla con un campo de texto para escribir un nombre y un botón de aceptar que, al pulsarse, recibe la información. No es hasta el momento en que pulsa «aceptar» que comienza el efecto en cadena. El botón llamaría al ViewModel enviando el contenido del campo de texto. Este haría una petición al UseCase, que consultaría al Repository en qué DataSources tiene una lista de nombres. Una vez que sabe dónde buscar esa información, la obtiene y pasa esa lista de forma recursiva.

Esta es la forma general en que funciona la Clean Architecture. Les dejaré un enlace a un proyecto de GitHub de ejemplo que utiliza dicha arquitectura.