anncode

[Android Native, Kotlin, Geek & Teacher]

🧠 Inversión de Dependencias vs Inyección de Dependencias

¿Inversión de Dependencias es lo mismo que Inyección de Dependencias? te suenan? la diferencia entre ellos suele ser una de las preguntas más concurridas en entrevistas de trabajo.

  • Inyección de Dependencias es un Patrón de Diseño
  • Inversión de Dependencias es un Principio SOLID (Dependency Inversion Principle DIP)

Dependecy Injection (Inyección de Dependencias)

Este es un Patrón de Diseño que nos dice que los objetos deben ser creados fuera y deben ser proveídos a un método, clase y/o módulo en partícular en lugar de ser él mismo quien los cree.

Por ejemplo, mira la clase Vehicle que en su método constructor necesita un objeto para existir, en este caso el objeto está siendo creado dentro del método, por lo tanto estaríamos violando el Patrón de Diseño Dependency Injection.

class Vehicle(
  val motor = GasMotor()
)

Arreglemos esto.

Extraemos la creación del objeto hacía fuera e independiente de la clase, de esta manera podemos crear un objeto fuera de la clase e inyectarlo.

class Vehicle(
  val motor: Movable
)

val motor = GasMotor()
val vehicle = Vehicle(motor)

Con esto ya estamos cumpliendo la Inyección de Dependencias ✅

He diseñado un Curso de Diseño Orientado a Objetos y Principios SOLID dónde te enseño a aplicar correctamente este principio en problemas reales, echale un ojo a este Cupón de Descuento.

Dependency Inversion Principle de SOLID

El principio dice:

Los módulos de alto nivel no deberían dependeer de los de bajo nivel.

Ambos deberían depender de abstracciones

Para entender este principio es necesario entender principalmente qué significa Alto y Bajo nivel.

Alto Nivel

Serán todas esas clases funciones y/o módulos que necesitan una dependencia, es decir, necesitan de otro objeto para poder crearse.

Por ejemplo: La clase Vehicle necesita un objeto motor para poder crearse, por lo tanto diríamos que Vehicle es una clase de Alto nivel.

class Vehicle(
  val motor: Movable
)

Bajo Nivel

Serán las dependencias en sí. Los objetos necesarios para crear una clase.

La característica principal para que sea de Bajo nivel es que no sea una abstracción (Interfaces y/o Clases Abstractas) sino objetos concretos.

Usando el ejemplo anterior.

Podemos identificar por su nombre, que Movable es una abstracción, y más específicamente una Interfaz.

Por lo tanto para que sea un objeto de bajo nivel necesitamos que motor sea un objeto concreto, es decir, motor podría ser de tipo ElectricMotor y GasMotor como se ve a continuación

class ElectricMotor : Movable()
class GasMotor : Movable()

Estas son clases de bajo nivel y si las instaciamos serían objetos de bajo nivel.

Violando el Principio de Inversión de Dependencias que dice en su primera parte: Los módulos de alto nivel no deberían dependeer de los de bajo nivel.

Instanciaríamos la clase Vehicle de Alto Nivel con un objeto de Bajo Nivel por ejemplo: GasMotor.

class Vehicle(
  val gasMotor: GasMotor
)

Esto hace que nuestra clase Vehicle esté acoplada a solo crear veículos con motor de gas, y cuando evolucionemos, hacer el cambio a motores eléctricos será muy doloroso.

Tener una clase con bajo acoplamiento nos ayuda a hacer software más flexible y escalable.

De hecho hay otro principio de diseño que nos dice que si tenemos «Bajo Acoplamiento y Alta Cohesión» nos ayuda a crear software más saludable.

Cómo detectar una Inversión de Dependencias vs una Inyección de Dependencias

Verás que ahora es muy fácil de entender y es que de acuerdo a la segunda parte del Principio de Inversión de Dependencias: Ambos deberían depender de abstracciones.

Para que exista una Inversión de dependencias necesitamos Depender de Abstracciones (Interfaz o Clase Abstracta)

Mientras que en la Inyección de dependencias simplemente es mantener la creación de objetos fuera de la clase, método y/o módulo e inyectarlos como dependencias.

Por ejemplo:

Aquí podemos ver que el Patrón de Inyección de Dependencias sí se cumple, ya que no estamos creando los objetos dentro de la clase, tenemos la posibilidad de crearlos fuera.

class Vehicle(
  val gasMotor: GasMotor
)

Sin embargo, el Principio de Inversión de Dependencias no se cumple por que no estamos dependiendo de Abstracciones.

Por lo tanto tenemos:

✅ Inyección de Dependencias

❌ Inversión de Dependencias

Otro Ejemplo:

Aquí vemos los dos principios aplicados pues podemos crear objetos fuera de la clase y además la clase dependende de una abstracción

class Vehicle(
  val motor: Movable
)

interface Movable { }

class ElectricMotor : Movable()
class GasMotor : Movable()

Por lo tanto tenemos:

✅ Inyección de Dependencias

✅ Inversión de Dependencias

Puedes explicarme en tu palabras cuál es la diferencia entre ellos? Explícame en los comentarios ✍

En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso con ejemplos reales, te dejé un regalo en este link para que lo adquieras a un precio especial.

Si te gustó esta clase no olvides compartirla haces un excelente trabajo divulgando conocimiento ⚡

4 thoughts on “🧠 Inversión de Dependencias vs Inyección de Dependencias

  1. Hola Ann, Muchas gracias por tu tiempo y tu dedicación para explicar estos 3 temas, me quedo muy claro todo lo que explicas.

    Saludos

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.