Este es el quinto y último principio de programación SOLID.
Significado
Este principio establece que las clases de alto nivel no deberían depender de las clases de bajo nivel. En su lugar las clases deberían depender de las abstracciones.
Además las abstracciones no deben depender de los detalles sino que los detalles deben depender de las abstracciones.
Con este principio se busca reducir las dependencias entre módulos buscando un menor nivel de acoplamiento entre clases.
Esto es indispensable en proyectos con muchos módulos en los que es necesario utilizar inyección de dependencias.
Ejemplo
Veamos el siguiente ejemplo en el que en nuestro proyecto tenemos una clase que nos permite el acceso a la base de datos en general que llamaremos CargadorDesdeBaseDeDatos y tenemos una clase PersonaEnBaseDeDatos que nos permite cargar datos de la clase Persona.
Para ello la clase PersonaEnBaseDeDatos tiene una propiedad de tipo CargadorDesdeBaseDeDatos que se utiliza como driver de acceso al sistema de almacenamiento de bases de datos de la aplicación.
class CargadorDesdeBaseDeDatos {
funcion obtenerDatosGenerales()
}
class PersonaEnBaseDeDatos {
propiedad datos = CargadorDesdeBaseDeDatos()
propiedad listaDePersonas
funcion cargaDatos() {
listaGeneral = datos.obtenerDatosGenerales()
listaDePersonas = convertirDatosGeneralesEnDatosDePersonas(listaGeneral)
}
}
En el ejemplo en la clase PersonaEnBaseDeDatos dentro de la función cargaDatos() hay una dependencia de la clase AccesoABaseDeDatos. Esto es un problema porque si un día necesitamos cambiar de sistema de base de datos o de obtener datos de Internet tendríamos que modificar demasiado código ya que ambas clases tienen una fuerte dependencia entre ellas.
Imaginemos por ejemplo que queremos incluir la opción de descargar los datos desde una API rest en Internet. El código se complicaría demasiado en todas las clases.
Solución
La solución a este problema es utilizar una abstracción que permita identificar un acceso a datos mediante una interface o protocolo, dependiendo de las posibilidades del lenguaje de programación.
Veamos el código.
interface AccesoADatos {
funcion cargaDatosDePersonas
}
class CargadorDesdeBaseDeDatos Implementa AccesoADatos {
propiedad listaDeDatos
funcion obtenerDatosGeneralesDesdeMySQL() {
listaDeDatos = cargaDesdeMySQL()
}
funcion cargaDatosDePersonas() {
obtenerDatosGeneralesDesdeMySQL()
return convertirATipoPersona(listaDeDatos)
}
}
class CargadorDesdeInternet Implementa AccesoADatos {
propiedad listaDeDatos
funcion obtenerDatosGeneralesDeInternet() {
listaDeDatos = descargaDeLaNube()
}
funcion cargaDatosDePersonas() {
obtenerDatosGeneralesDeInternet()
return convertirATipoPersona(listaDeDatos)
}
}
class PersonaEnBaseDeDatos {
propiedad datos = AccesoADatos
propiedad listaDePersonas
funcion constructor(inyeccion: AccesoADatos) {
datos = inyeccion
}
funcion cargaDatos() {
listaDePersonas = datos.cargaDatosDePersonas()
}
}
Con esta solución podemos inyectar cualquier clase del tipo interface AccesoADatos en el constructor de la clase PersonaEnBaseDeDatos. De esta forma podemos cambiar cómo accedemos a esos datos inyectando cualquier clase que implemente la interfaz AccesoADatos consiguiendo un mayor nivel de desacoplamiento entre clases. De esta forma tanto el módulo de alto nivel como el de bajo nivel dependen de abstracciones, por lo que se cumple el principio de inversión de dependencias y además, esto nos obliga a cumplir el principio de Liskov, ya que las clases que accederán a cualquier base de datos son intercambiables entre ellas ya que todas implementan la interfaz de AccesoADatos.
