Xuaps

Amplificador

Principios diseño: DIP, IoC, DI

No me considero un purista, siempre he pensado que hay que beber la información, extraer la esencia y aplicarla en tu contexto. Pero a veces conviene ponerse tiquismiquis con ciertos conceptos porque nos ahorrará muchos quebraderos de cabeza.

No se por qué, pero DIP, IoC y DI son términos que normalmente se confunden y se usan indiferentemente. No me preocupa, en la práctica parece que el concepto ha asentado y que todos lo tenemos más o menos claro. Pero cuando se propone aplicar estos conceptos en un proyecto para poder inyectar mocks en los tests me doy cuenta de que, tal vez, vale la pena pararse un poco y recapacitar.

Dependency inversion principle (DIP) es un principio de diseño que nos habla sobre acoplamiento, específicamente sobre no acoplar nuestro código a implementaciones concretas si no a abstracciones. Una forma de conseguirlo es aplicar Inversion of Control (IoC), un concepto muy genérico que no se aplica sólo a las dependencias y que queda resumido en el Hollywood principle: “no nos llames, nosotros te llamaremos”. Y con todo esto llega Dependency Injection (DI), un tipo específico de IoC que nos ayuda a conseguir DIP. Claro, ¿verdad?

Lo importante de todo esto es que aplicando estos principios y técnica conseguimos un código menos acoplado y más testable, no al revés. No usamos todos estos conceptos para poder hacer tests unitarios. Ya lo se, parece lo mismo pero no lo es. Si empiezas a introducir estos cambios en tu código de forma puntual para poder hacer algunos tests, terminarás con un código plagado de puertas traseras, contaminado por los tests. Sin embargo, si dejas que los tests te alumbren el camino y te señalen esos malos olores, podrás volver al dibujo completo y decidir qué cambios quieres incluir en tu diseño, terminarás con un código más desacoplado y consistente.

Cuando escribes código partiendo de las pruebas tomas decisiones inconscientes: cómo será tu api, qué devolverá este método o aquel, qué recibe en la llamada… La atalaya de las pruebas es muy buena para este tipo de decisiones ya que las tomas desde el punto de vista de quién usará tu API. Sin embargo, en mi opinión, hay algunas decisiones, como aplicar un patrón arquitectónico, que deben ser conscientes, evaluadas y razonadas porque las pruebas nos tienen que guiar pero a veces hay que modificar la ruta y el GPS eres tu.