Existen muchos proyectos del tipo Simple Injector para varios lenguajes de programación que permiten, por el nombre de una clase, interfaz o espacio de nombres, y en ocasiones una carpeta, registrar una clase o un grupo completo de clases unidas por esta característica en algún caso. Esto es con el propósito de instanciar automáticamente un objeto sin especificar explícitamente sus dependencias. Este registro de un grupo de objetos por una característica común en el registro con el propósito de una mayor instanciación lo llamo registro automático de dependencias.
Si crea una instancia explícitamente de una clase al registrarla en el registro de dependencia, este no es el tema de este artículo.
¿Y qué hay de malo en eso?
En esta publicación, hablaré sobre mis frustraciones con los proyectos que usan el registro automático de dependencias. Vayamos en orden.
Tiempo de ejecución vs tiempo de compilación
Usando la herramienta de registro automático de dependencias, estamos moviendo la verificación de integridad de las dependencias registradas al tiempo de ejecución. Es decir, si en el momento de lanzar el programa no tenemos la implementación de la interfaz necesaria para ejecutar el código, lo aprenderemos en el mejor de los casos al inicio de la aplicación, y en el peor, ya durante el funcionamiento del sistema y de los usuarios.
He aquí un ejemplo. Si en el proyecto el registro de algunas clases ocurrió, digamos, por su espacio de nombres, y en algún momento movió la clase desde allí, entonces aprenderá sobre el problema en tiempo de ejecución. Lo mismo ocurrirá con el registro automático a través de la interfaz, con la única diferencia de que moverse no será un problema, pero quitar la interfaz te traerá un problema, del que conocerás después de iniciar la aplicación.
Refactorizar es mucho más complicado
No solo refactorizar, sino también aprender el código se vuelve muy difícil. Esto se debe a que al utilizar el registro automático de dependencias, se pierde el acceso a las capacidades modernas de los entornos de desarrollo, lo que nos permitiría averiguar quién está usando esta clase con un solo clic (buscar referencia) y responder las siguientes preguntas:
- ¿Puedo eliminar esta clase?
- ¿Puedo mover esta clase a otro espacio de nombres / carpeta?
etc.
Además del hecho de que se nos priva de la oportunidad de verificar la integridad de las dependencias requeridas durante la compilación, cualquier refactorización es la esperanza de que tengamos un mecanismo de tiempo de ejecución en forma de pruebas, verificaciones de árboles de dependencia y similares. Y la esperanza es que funcione. Cabe destacar que estos mecanismos no solo no garantizan al 100% que la composición del código sea la correcta, sino que además son mucho más lentos que la compilación.
Ocultar la verdadera complejidad del sistema
Al crear instancias de clases manualmente y todas sus dependencias, es posible que se sienta bastante intimidado por la monstruosidad del archivo en el que se llevará a cabo toda esta acción. Mirando miles de líneas de código para instanciar clases y comparándolas con una docena cuando utilizo el registro automático de dependencias, realmente quiero sucumbir a la tentación e ir al "lado oscuro".
Pero, ¿qué nos dicen estas miles de líneas de código de instanciación de objetos? El hecho de que este módulo es complejo, grande y deberíamos pensar en estructurarlo mediante la asignación de submódulos (que ellos mismos instancian explícitamente sus dependencias), o dividir este módulo en varios.
Puede parecer abstracto, pero eliminar momentos tan incómodos como instanciar cientos de objetos de nuestros ojos conduce al hecho de que el tamaño del proyecto crece incontrolablemente y, como resultado, perdemos el momento en el que debería dividirse en varios proyectos.
Dependencias extra
Al registrar dependencias y no controlar su uso, tarde o temprano llegamos a una situación en la que, al iniciar la aplicación, se registran significativamente más clases de las que realmente se requieren. Simplemente agregar a una carpeta o implementar una interfaz puede resultar en que esta clase se registre en el caso general.
Resumen
¿Es posible vivir con todas estas desventajas y no notarlas? ¡Seguro! Pero creo que desarrolla hábitos de desarrollo incorrectos. La cuestión es que la compilación y la mecanografía de código son herramientas para comprobar la corrección del sistema. Rechazándolos, llegamos a la conclusión de que el sistema se vuelve frágil, por lo que los desarrolladores tienen miedo de cambiar algo en él. Y el miedo de los desarrolladores a cambiar el código ya lleva al hecho de que la calidad de la base del código se degrada, después de lo cual se convierte en un proceso costoso realizar cambios en dicho código.
¿Qué tiene de bueno el registro automático de dependencias?
Y realmente, ¿qué es bueno? Sugiero discutir en los comentarios por qué este método ganó popularidad. Seguro que tiene fans entre sus lectores.