SOLID – Principio de Inversión de Dependencias

1. Hola
   Felicidades por el video.

   Quería recomendar un artículo muy bueno de la web de Martin Fowler que ayuda a distinguir bien entre IOC, DIP y DI, y a entender la aplicación del principio y las ventajas que aporta en diferentes casos de uso:

   DIP in the Wild, Brett L. Schuchert
   http://martinfowler.com/articles/dipInTheWild.html

   Saludos,
   Manuel

   Responder

   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

         1. Hay IDEs como PhpStorm que te advierten de este tipo de prácticas: https://i.imgsafe.org/d49bf078bd.png 🙂

            Responder

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.