anncode

[Android Native, Kotlin, Geek & Teacher]

Cursos de Anahi Salgado @anncode 0 (0)


Lo que aprenderás

  1. Fundamentos de programación de manera profunda
  2. Desarrollo Clean con Kotlin
  3. Análisis de Algoritmos con Kotlin
  4. Programación Funcional

Aprende Kotlin desde cero con sus principios de programación.

Domina las buenas prácticas del Código Limpio (Clean Code) aplicables a cualquier lenguaje.

Conoce las estratégias para hacer análisis y resolución de Algoritmos con Kotlin, uno de los skills más solicitados en entrevistas de compañías Tech Top en el mundo.

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

🤹‍♀️ Jetpack Compose en tu proyecto de Android Views 5 (1)

Al fin Jetpack Compose 1.0 🔥 fue liberado en este 2021 y llegó la hora de integrarlo a nuestros proyectos existentes de Android.

Mira todas las combianciones que puedes hacer al mezclarlo con los views de tu proyecto:

  • Inserta un Composable en un Fragment
  • Inserta un Composable en un View
  • Crea una pantalla entera Composable y hazla interactuar con tus otras screens
  • Inserta un View en un Composable

Todo te lo explico aquí 🤯👇

Te dejo los slides para que nunca se te olvide.

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

👩‍🏫 Android MVVM Clean Architecture + Dagger Hilt 5 (2)

Dagger Hilt es el framework de Inyección de Dependencias que nos ayuda a:

  • Reutilización
  • Centralización
  • Manejo de Ciclo de vida de objetos

Mira la clase para implementarlo usando una Architectura MVVM Clean 👇

Te dejo los slides para que nunca se te olvide.

Dagger Hilt me encanta, y la mejor noticia es que ya tenemos release.

Ya lo probaste?

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