Principio de inversión de dependencias

El Principio de Inyección de Dependencias es una técnica esencial para crear aplicaciones modulares y fáciles de probar. Este principio se basa en la idea de que las clases de alto nivel no deben estar rígidamente vinculadas a sus dependencias de bajo nivel; en su lugar, ambas deben depender de abstracciones. En la práctica, esto significa que las clases no deben crear o buscar sus propias dependencias, sino que deben serles proporcionadas, generalmente a través de interfaces. Dicho de otra manera, las dependencias que se inyectan en las clases deben ser meros contratos (interfaces), y no implementaciones concretas (clases con métodos desarrollados).

Ejemplo sencillo

Consideremos, por ejemplo, una interfaz ProductRepository en una aplicación de comercio electrónico. Esta interfaz define los métodos esenciales para trabajar con productos, como obtenerlos, agregarlos y eliminarlos. Luego, tenemos dos implementaciones concretas de esta interfaz: SQLProductRepository, que interactúa con una base de datos SQL, y InMemoryProductRepository, que utiliza una estructura de datos en memoria para pruebas o entornos de desarrollo.

Spaghetti

/** Example whitout DIP principle*/
final readonly class SQLProductRepository implements ProductRepository
{
    // Implementación utilizando base de datos SQL
}

final readonly class InMemoryProductRepository implements ProductRepository
{
    // Implementación en memoria para pruebas o desarrollo
}

final readonly class ProductManager
{
    public function __construct(private SQLProductRepository $repository)
    {
    }

    public function processProduct($id) {
        $product = $this->repository->getProductById($id);
        // Lógica para procesar el producto...
    }
}

En este ejemplo, ProductManager crea directamente una instancia de SQLProductRepository. Esto significa que está fuertemente acoplado a una implementación específica del repositorio. Si decidimos cambiar la fuente de datos a InMemoryProductRepository para pruebas o desarrollo, tendríamos que modificar el código de ProductManager, y lo mismo aplicaría si aparecieran nuevas implementaciones de ProductRepository.

DIP

/** Example with DIP principle*/
interface ProductRepository
{
    public function getProductById($id);
    public function addProduct($product);
    // Otros métodos relevantes...
}

final readonly class SQLProductRepository implements ProductRepository
{
    // Implementación utilizando base de datos SQL
}

final readonly class InMemoryProductRepository implements ProductRepository
{
    // Implementación en memoria para pruebas o desarrollo
}

final readonly class ProductManager
{
    public function __construct(private ProductRepository $repository)
    {
    }

    public function processProduct($id)
    {
        $product = $this->repository->getProductById($id);
        // Lógica para procesar el producto...
    }
}

En este caso, ProductManager puede funcionar tanto con un SQLProductRepository como con un InMemoryProductRepository, lo que aumenta enormemente su flexibilidad y facilita la realización de pruebas unitarias. Al inyectar la dependencia, ProductManager está acoplado solo a la interfaz ProductRepository, no a una implementación específica, permitiendo así una mayor modularidad y facilitando el mantenimiento y la extensión del código.

Para finalizar

---

Principios SOLID: Principio de Inversión de Dependencia DIP

El principio de inversión de dependencia, con el cual desacoplaremos los módulos de nuestros sistemas.

#Video tutorial#hdeleon#SOLID