anncode

[Android Native, Kotlin, Geek & Teacher]

🧠 Inversión de Dependencias vs Inyección de Dependencias 5 (3)

¿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 ⚡

🎧 Programa bien, programa Clean Code {Podcast} 5 (4)

Clean code es tu gesto de empatía como autor de software para el programador que vendrá a leerte. En este podcast te cuento un resúmen del libro Clean Code de Robert C. Martín mejor conocído como el Tío Bob.

Trae tu bebida favorita y platiquemos un rato.

🌱 Clean Architecture desde cero 5 (5)

¿Qué es Clean Architecture?

Aquí hay dos palabras muy importantes en juego

  1. Clean
  2. Architecture

✨ Clean

El arte de limpiar.

Clean literalmente traducido significa Limpio y tener algo limpio está totalmente relacionado con que esté ordenado. (aunque no es directamente proporcional pero definitivamente están relacionados)

Ordenar, poner cada cosa en su lugar.

Tu ropa tiene un lugar, las llaves de tu casa tienen un lugar, el cargador de tu celular tiene un lugar, y en medida que respetemos esto, nos traerá una multitud de beneficios.

😉 Encontrar tus llaves y/o cargador nunca más será un problema si todo tiene un órden.

I know that feel bro | Wiki Memes Pedia | Fandom

Además traer más ropa a tu closet será mucho más sencillo de integrar si está correctamente ordenada.

En realidad relacionar el termino Clean del software con Órden me gusta mucho porque genera mucho valor. Así como los ejemplos que acabamos de ver parecen hacer tu vida más fácil, aplicar Clean a tus proyectos de software hace más fácil:

  1. Detectar y Resolver Bugs.
  2. Integrar nuevas características a tus proyectos.
  3. Optimizar tu equipo de desarrollo.

Si como programador pasas la mayor parte de tu tiempo leyendo código, desde luego vas a querer que todo lo que esté ahí sea lo más legible y ordenado posible. Esta es la escencia del uso de la palabra Clean en el Software.

Aplicar Clean a tus proyectos te llevará a hacer lo siguiente:

  1. Delegar responsabilidades – Ordenar.
  2. Ordenar nos llevará a separar y categorizar mejor.
Decluttering Queen Marie Kondo Is Now Selling Tiny Boxes – SheKnows

3. El deseo de tener legibilidad nos hará colocar estándares para escribir código que nos permitan leer mejor y más rápido. Por ejemplo: Usar nombres que se puedan buscar y que sean habituales al negocio, evitar anidamiento excesivo, evitar clases muy largas, etc.

Robert C. Martín es el defensor del termino Clean, más o menos es el Marie Kondo del software.

Gracias a la influencia del Tío Bob, hoy sabemos que podemos aplicar Clean a tres cosas:

  1. Code Clean Code
  2. Architecture Clean Architecture
  3. Agile Clean Agile

Este capítulo habla especialmente sobre Clean Architecture y quiero centrarme meramente en ello. Escucha mi Podcast sobre 🎧 Clean Code Aquí

Pero ¿cómo podemos tener nuestro proyecto lo más Clean / Ordenado posible? Acompañame a ver el siguiente concepto.

👷‍♀️ Architecture

Arte y técnica de diseñar, proyectar y construir

Wikipedia

Literalmente el concepto de Arquitectura aplicado en la Construcción, el Diseño y el Arte, puede ser aplicado de la misma forma en el software.

Aplicar una arquitectura le da un sentido de proyección hacía el futuro a nuestros proyectos y aplicaciones.

Las preguntas serían: ¿Por qué quiero hacer esto? ¿Por qué es importante proyectar mi código? No debería enfocarme en que el código funcione? ¿Qué significa proyectar mi código hacia el futuro?

Como programadores tenemos dos trabajos:

  1. Hacer que el código funcione ✅
  2. Proyectarlo al futuro: hacerlo mantenible 🌠
    (déjame en los comentarios si conoces una mejor palabra para describir esto)

Seguro pensabas que tu única responsabilidad era la número 1. no te preocupes antes yo también lo creía, lo importante es que estamos aprendiendo juntos.

Proyectar el código hacía el futuro es darle una estructura, es dárle el órden (Clean 😎) que se merece, para que implementar nuevas cosas y resolver bug’s sea lo más sencillo posible y con la menor cantidad de desarrolladores posibles.

Existen algunos modelos que nos ayudan a ordenar la estructura de nuestro código en Capas tal vez has escuchado el Modelo de Capas o Layers Model. Estos pueden ir desde tener una sola capa donde se concentre todo el código (por supuesto, nada clean/ordenado que proyecte nuestro código al futuro), hasta tener N capas.

Tío Bob nos recomienda estructurar / ordenar nuestro proyecto en 3 capas principales.

  1. Presentation: Interface de Usuario UI.
  2. Domain: Todas las reglas de negocio, también se llama business logic en inglés.
  3. Data: Todo lo que tega que ver con la persistencia de datos.

En los siguientes capítulos voy a presentarte todos cada uno de ellos a detalle.

👉Clean Architecture es:

La forma de ordenar y proyectar nuestro código hacia el futuro, para que añadir nuevas características y resolver bugs sea lo más simple posible con la menor cantidad de desarrolladores.