Principio de Inversión de Dependencias
Este es el último principio que es parte del acrónimo SOLID, conocido como Dependency Inversion principle. El principio dicta que módulos de nivel alto no deberían de depender de módulos de nivel bajo. Los dos deben de depender de abstracción. Esto nos permite el desacoplamiento de los módulos.
Imagina que eres dueño de un restaurante y tienes un programa donde integraste una funcionalidad que te permite notificar a UberEats que la comida ya está lista para recoger y entregar.
Podemos ver que el restaurante logra notificar al conductor de UberEats con éxito que la orden ya está lista para entrega. ¿Qué pasaría si el restaurante decide cambiar a o agregar otra empresa de delivery? Tocaría entrar a la clase de Restaurante y hacer los cambios necesarios ya que las clases están acopladas lo que causa dependencias. Idealmente, esa no es el mejor método a seguir pero si puede ser funcional.
Lo recomendable es aplicar el principio de inversión de dependencias ya que nos permitirá desacoplar las clases y poder reutilizar las clases si es necesario. Al aplicar este principio, la misión es que no exista la necesidad de que las clases dependan entre sí, sino que dependan de abstracciones.
Al aplicar este principio, podemos ver que ya no hay dependencias ya que las clases dependen de la abstracción. Esto nos permite agregar más compañías para trabajar si es necesario o reutilizar las clases.
Otro principio que cubre SOLID es Single Responsibility Principle o mejor conocido como Principio de Responsabilidad Única.
