A continuación veremos el último y quinto principio correspondiente a la D en SOLID, que nos habla del Principio de Inversión de Dependencias o en inglés Dependency Inversion Principle. Este principio menciona algunas reglas referentes al uso de abstracciones y separación de conceptos.
El principio nos dice que, los módulos de alto nivel en nuestro sistema no deberían depender de aquellos de bajo nivel sin embargo ambos deberían de depender de las abstracciones y estas últimas no deben depender de los detalles.
Suena bien pero, ¿Qué significan exactamente estos conceptos?
Entendemos por código de alto nivel aquel que contiene reglas de negocio y está más orientado a los procesos de manera que está más lejos de los módulos para la entrada y salida de datos.
Por el contrario el código de bajo nivel está más cercano a la entrada y salida de datos e interactúa con servicios y/o hardware o contiene la funcionalidad para conectar con las reglas del negocio y por último las abstracciones son las interfaces o clases abstractas de las que dependen nuestras clases.
Las abstracciones describen el qué es lo que se realiza, como hacer un cálculo o enviar un mensaje sin exponer los detalles. Estos detalles son los que describen el como se realiza el mensaje, como se realiza el cálculo o de que manera se va a enviar ese mensaje.
Entonces resumiendo un poco: Los módulos que contienen las reglas del negocio y los procesos no deben de depender de los módulos más cercanos a la entrada y salida de datos, mientras que ambos deberían depender de Interfaces o clases base/abstractas.
Y también el realizar determinada acción en una interfaz o clase base, no debería de depender del cómo se va a realizar ni implementarlo por si mismo.
Ten en cuenta esto cuando crees instancias de clases y dependencias como “new” ya que de esta manera estarás acoplando el código a esa dependencia. No es que sea malo o prohibido sin embargo es para tener en cuenta y probablemente puedas remediarlo utilizando inyección por constructor u algún patrón que facilite esta tarea.
Como se mencionó al inicio de estos artículos, estos principios no es que estén tallados en piedra y deban implementarse al 100 en todos y cada uno de los desarrollos. Muchas personas podrán tener interpretaciones diferentes o, de acuerdo al software en el que trabajan tendrán que adaptar muchas de sus prácticas mismo que puedas hacer tú mientras analizas él código e implementar solo lo justo y necesario así te convenga. También recuerda que implementar demasiada abstracción en un desarrollo en una etapa que probablemente no lo requiera, va a aumentar la complejidad del mismo.
Espero que te haya sido de ayuda a comprender un poco más de estos principios y a seguir aprendiendo!