El Contexto Importa
El hecho de que el proyecto esté desarrollado en JAVA nos permite explicar este punto tan relevante en esta guía.
Al referirme al contexto, no estoy hablando de la clase Context del framework de Android 😁, sino de entender el entorno del proyecto para tomar las decisiones de implementación más adecuadas. Para ello, nos centraremos en el enfoque Paquete por Componente, donde se menciona:
El proyecto tiene un intento de este enfoque en su ramas : package_by_component_Main y package_by_component_Secondary
La palabra intento no está ahí por casualidad, sino para indicar que no es posible alcanzar el objetivo de Paquete por Componente. Para abordar este tema, analizaremos la rama package_by_component_Main:
El objetivo del enfoque paquete por componentes es idealmente ofrecer únicamente los servicios del componente a través de una interfaz limpia y agradable, ocultando los detalles innecesarios de la implementación que están detrás de los servicios.
| Servicio como punto de entrada | Visible para el consumidor |
|---|---|
 |
 |
En el diagrama de paquetes, observamos una parte del proyecto donde MovieServices es el punto de entrada para acceder a los servicios del paquete Movie, que deben ser visibles para el consumidor como se muestra en la imagen de exposición de servicios. Adicionalmente, los errores de servicio se adaptan para su uso en el módulo app, como se ve aquí.
Sin embargo, la realidad muestra que otros elementos, aparte del servicio, son visibles cuando no deberían serlo.
| Mas de una entrada | Elementos que deberian ocultarse |
|---|---|
 |
 |
En el diagrama de paquete, podemos ver que la interfaz MovieLocalRepository es visible cuando en realidad no debería serlo, como también sucede con la interfaz MovieRemoteRepository. Estos elementos debido al contexto no se pueden ocultar y están marcados en la imagen con un rectángulo rojo.
Los módulos de dagger, los ámbitos, los calificadores y otros elementos de configuración son excepciones porque se relacionan con el Componente Main.
La respuesta rápida podría ser: "Java es el problema porque no ofrece más formas de ocultar elementos dentro del módulo, a diferencia de Kotlin que ofrece la palabra clave internal para especificar que un miembro es visible dentro del módulo donde está definido pero no fuera de él."
Lo anterior no es del todo cierto; aunque la encapsulación en Java 8 (lenguaje utilizado por todos los módulos de este proyecto) tiene limitaciones, podríamos optar por Java 9 y su sistema de módulos, que garantiza la encapsulación requerida por el enfoque elegido. Sin embargo, la realidad es que Android no soporta el sistema de módulos de Java 9. Por lo tanto, entender el contexto implica conocer las opciones más apropiadas para el entorno específico, como utilizar Kotlin en lugar de Java en este contexto.
Además de eso, con Kotlin tenemos una mejor forma de manejar flujos asíncronos sin recurrir a librerías externas, como RxJava, entre otros beneficios. Podríamos decir que Java es muy útil, pero no tanto en este contexto (Android).
Si, a pesar de conocer el contexto, se quisiera continuar con el desarrollo actual y cumplir con el enfoque elegido, se podría considerar lo siguiente:
- Uso de herramientas de análisis estático: En estas condiciones, el uso de estas herramientas estaría justificado.
- Poner todo el código en un solo lugar: Si pusiéramos todo el código del paquete movie junto, podríamos mostrar solo lo necesario. Sin embargo, no habría la separación de preocupaciones que establece el enfoque Paquete por Componente.
- Mayor modularización: A este nivel, es una opción poco práctica, además de que dejaría de ser el enfoque que se quiere cumplir.
Aunque todas estas alternativas abordan el problema, no resuelven el problema de fondo.
Con esta sección, no pretendo decir que el contexto lo sea todo, sino más bien que en algunas situaciones debemos considerar detenidamente las opciones disponibles frente a un escenario que requiere anticipar sus posibles implicaciones en el proyecto.
