SOLID: Inversión de Dependencia

Introducción al principio

Fue propuesto inicialmente por Robert C.Martin (Uncle Bob), para mi es el principio más importante.

Este principio indica lo siguiente:

Los módulos de alto nivel no deberían depender de los de bajo nivel, ambos deberían depender de abstracciones.

Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.

Mediante este principio ocultamos los detalles de implementación que en básico en una buena arquitectura.

La principal ventaja de aplicar este principio es la flexibilidad que nos aporta. Cuando estamos haciendo test, podemos reemplazar dependencias reales por objetos dobles que se comportan de forma dirigida para para el test.

Esta flexibilidad también nos aporta más escalabilidad ya que vamos a poder sustituir componentes sin que los clientes que los consumen se vean afectados ya que dependen de la abstracción y no de la implementación concreta.

Otro punto importante del principio es que las los detalles dependen de las abstracciones y no al revés. Es fundamental que la abstracción se defina en base a las necesidades del cliente y no en las capacidades de la implementación, de lo contrarío la abstracción estaría bastante acoplada a la implementación y teniendo así menos flexibilidad.

Ejemplo visual

¿Soldamos directamente una lámpara al cableado eléctrico de un pared?
.

No, creamos abstracción enchufe y así podemos enchufar cualquier aparato electrónico.

Ejemplo de código

Tenemos una abstracción y dos implementaciones.

public interface IAmazonAPIClient
{
}

public class SOAPAmazonAPIClient:
             IAmazonAPIClient
{
}

public class RESTAmazonAPIClient:
             IAmazonAPIClient
{
}

Y un cliente que depende de la abstracción.

public interface IProductRepository
{
   private IAmazonAPIClient;
}

Curso y artículos relacionados

• Curso Clean Architecture
• Curso testing

Conclusiones

Aplicando el Principio de Inversión de Dependencia estamos haciendo nuestro código más flexible y escalable de forma que podemos realizar cambios sin afectar a otras partes. Básicamente lo que conseguimos es ocultar los detalles de implementación.