Estaba soldando la lámpara directamente a los cables de corriente.
Tuve que cambiar el modelo que siempre usaba por uno ligeramente diferente y mis problemas de diseño vinieron a perseguirme. Mi entrenamiento dependía de detalles que deberían haberle sido irrelevantes. Así que era hora de aprender el concepto de Dependency Inversion.
En programación orientada a objetos hay cinco principios que ayudan a que el código no se vuelva infernal: SOLID. Single responsability , Open-closed, Liskov substitution, Interface segregation y Dependency Inversion suenan muy razonables en el papel (o en vídeo), pero en la práctica son súper fáciles de ignorar.
El que me interesa hoy es Dependency Inversion, o Inversión de Dependencias, y puede ser explicado muy fácilmente con un ejemplo: “No deberías soldar la lámpara directamente los cables de corriente”.
Un meme clásico para explicar Dependency Inversion.
La idea es sencilla: al soldar la lámpara a los cables estoy haciendo que sea muy difícil usar algún otro electrodoméstico en ese mismo lugar, y también es muy difícil cambiar de lugar la lámpara. Y así como los electricistas solucionaron ese problema con una interfaz entre la lámpara y la red eléctrica de la casa -un enchufe-, del mismo modo, una interfaz era la solución al problema de cambiar fácilmente de modelos.
Mi entrenamiento necesitaba saber muy poco de mi modelo en realidad. Solo… Probablemente eso no sería un problema al usar otros frameworks, pero nosotros estamos usando Jax puro e implementando las redes desde cero 😬.
Más aún, las versiones alternativas de mi modelo eran muy similares; todas consistían en un paso de preprocesamiento del input, para luego pasarlo por una red neuronal, y finalmente aplicar un postprocesamiento al output.
