SOLID – Principio de Inversión de Dependencias

En este segundo vídeo de la serie de SOLID vamos a ver qué es y qué beneficios aporta el Principio de Inversión de Dependencias. Como de costumbre, vamos a enfocarlo de la manera más práctica posible, refactorizando un código para pasar a aplicar este principio.

En los vídeos anteriores ya vimos cómo configurar namespaces siguiendo PSR-4 y usar el autoloader de Composer, cómo aplicar el estándar PSR-2 de estilo de código y, más concretamente en la serie sobre SOLID, ya hemos visto el Principio de Responsabilidad Única y de Segregación de Interfaces. Os recomiendo echarles un vistazo 🙂

Índice del vídeo

  • 1:03 – Explicación código base (contexto)
  • 2:50 – Escenario 1: Código altamente acoplado y creando las instancias de los colaboradores en el punto en el que se necesitan
    • 3:55 – ¿Por qué es malo el acoplamiento de código?
    • 6:10 – Diagrama de clases del escenario 1
  • 7:10 – Escenario 2: Refactoring para introducir el concepto de inyección de dependencias. Código altamente acoplado pero creando las instancias de los colaboradores fuera de la clase cliente
    • 9:00 – ¿Qué beneficios tiene la inyección de dependencias?
  • 10:39 – Escenario 3: Refactoring para aplicar el Principio de Inversión de Dependencias (Dependency Inversion Principle, DIP). Código desacoplado y cambiable.
    • 11:38 – Explicación de la interface introducida. Diseño por contratos
    • 13:35 – ¿Qué beneficios tiene la inversión de dependencias?
    • 15:30 – Diagrama de clases aplicando el principio de inversión de dependencias
    • 16:05 – Inversión de dependencias como nunca te lo han explicado 😀

Vídeo

Material relacionado

Siguientes vídeos

  • ¡Entrevista!
  • DTOs / Modelos de dominio anémicos vs Modelos de Dominio (Nivel medio)
  • Composition over Inheritance – Un punto de inflexión (Nivel medio)
SHOWHIDE Comments (10)

    1. ¡Buenas Manuel!

      Merci por el artículo. No lo conocía y pinta bastante interesante. Curioso el entender la introducción de Value Objects para representar Strings como la aplicación de inversión de dependencia con String. Nunca me había planteado los Value Objects con ese enfoque 😮

      A ver si saco tiempo para leerlo más a fondo, que seguro que salen cositas interesantes para poder hacer un vídeo de él 😀

      Saludos!!

      Responder

  2. Muy bueno el vídeo. Lo estoy poniendo en práctica en un proyecto nuevo en symfony, pero tengo una duda que quizá sea básica pero que no consigo resolver.

    Inyecto una interfaz en un controlador.
    Digo a mi Contenedor de dependencias qué clase implementa esa interfaz (la clase contiene muchos más métodos que los obligados por la interfaz de marras)
    ¿Es lógico que tenga disponibles los métodos de marras de la clase no definidos en la interfaz? Tendría más sentido si solo tuviera disponibles los de la interfaz.

    Quizá el contenedor de dependencias debería ser un poco más inteligente y no exponerme esos otros métodos. Trabajando con C# y castle windsor como framework IoC funciona así, pero en Symfony no. Alguno miente 😉

    PD: Abrí pregunta en stack y por ahora lo que me dicen es que es normal que tenga acceso a todos los métods de la clase, meh
    http://stackoverflow.com/questions/40971189/how-to-inject-interfaces-not-class-in-symfony3?

    Responder

    1. Buenas David!

      Te he respondido en Stack Overflow: http://stackoverflow.com/a/41077177/967124 🙂

      El resumen es que, a pesar de que PHP tenga Type Hintings, no es hasta el momento de ejecución (runtime) cuando resuelve los métodos a llamar. Esto, a pesar de que personalmente no soy partidario de ello, permite cosas como el Duck Typing ( https://en.wikipedia.org/wiki/Duck_typing ).

      Aquí te dejo un ejemplo simplificando el caso que me pasas con el que verás más claro a lo que me refiero. En el caso de una implementación de la interface que no contenga el método que no pertenece a la interface, sí peta; pero en el caso contrario el comportamiento esperado es que se ejecute sin problemas: https://3v4l.org/mZcRq

      Lo importante es que si realmente vamos hacia una programación que basa el DIP en la inyección de dependencias mediante contratos, no deberíamos invocar a más métodos que los que nos exponga ese contrato. Sólo así estaremos realmente aprovechando los beneficios que nos brinda esa interface: Desacoplarnos de la implementación para poder cambiarla a nuestro antojo sin necesidad de cambiar la clase que recibe la instancia inyectada.

      Saludos!

      Responder

      1. Gracias por la respuesta, a veces olvido que esto es php con todas sus virtudes y defectos.

        Parece que no podemos evitar que los devs añadan métodos a las implementaciones y las usen sin actualizar a su vez la interfaz. Al menos podemos obligarles a implementar los métodos realmente necesarios.

        De nuevo, agradecerles su trabajo.

        Responder

Leave a Reply

Your email address will not be published.