ruby - para - patron de inyeccion
Bibliotecas de inyección de dependencia de Ruby (3)
Jamis Buck, quien escribió Copland and Needle, publicó aquí sobre Needle, la inyección de dependencia y su utilidad en un mundo de Ruby.
Es largo, pero vale la pena leerlo, pero en caso de que quiera el párrafo único más relevante para su pregunta, sugeriría este, justo antes del final:
Los marcos DI son innecesarios. En ambientes más rígidos, tienen valor. En entornos ágiles como Ruby, no tanto. Los patrones en sí pueden seguir siendo aplicables, pero ten cuidado de no caer en la trampa de pensar que necesitas una herramienta especial para todo. Ruby es Play-Doh, ¡recuerda! Mantengámoslo de esa manera.
HTH
He estado mirando algunas bibliotecas de inyección de dependencia de Ruby. En particular, revisé Needle y Copland . Han existido por bastante tiempo, pero no muchos usos.
¿Cuáles son algunos de los pros y los contras del uso de estas dos bibliotecas? Seguramente parece que muchas bibliotecas / frameworks podrían hacer un buen uso de estas dos bibliotecas, por ejemplo, Merb / Datamapper''s Hook .
Aquí hay otro IoC http://alexeypetrushin.github.com/micon
Lo usé como un componente central de mi framework web (no Rails), puedes verlo trabajando aquí - http://ruby-lang.info (este sitio funciona con él). Y me ahorró una gran cantidad de tiempo y código, así que personalmente encuentro IoC muy útil (en algunas situaciones).
Los marcos DI son innecesarios. En ambientes más rígidos, tienen valor. En entornos ágiles como Ruby, no tanto. Los patrones en sí pueden seguir siendo aplicables, pero ten cuidado de no caer en la trampa de pensar que necesitas una herramienta especial para todo. Ruby es Play-Doh, ¡recuerda! Mantengámoslo de esa manera.
Vi hablar de Jamis Buck, y estoy de acuerdo y en desacuerdo con él, he aquí por qué http://ruby-lang.info/blog/you-underestimate-the-power-of-ioc-3fh
http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/ : este es otro artículo mucho menos dogmático que el artículo de James Buck. La conclusión es que no necesita inyección de dependencia porque Ruby ofrece muchas buenas alternativas que funcionan igual de bien y que realmente no existen en el mundo de Java.
Una de esas alternativas es mixins, que es algo que Java no tiene y la otra es la capacidad de sobrescribir / redefinir casi cualquier cosa en el idioma. Otras características incluyen el tipado dinámico en el que básicamente puede enviar cualquier mensaje a cualquier objeto y si proporciona una implementación para ese mensaje, las cosas simplemente funcionan. Todas estas cosas trabajan juntas para eliminar gran parte de la necesidad de un marco DI. El patrón de diseño como tal también sigue siendo válido en Ruby y, a veces, tiene sentido usarlo.
Otro punto sobre DI que Alexey Petrushin también menciona es que la inyección de dependencia es principalmente un patrón de diseño y que las herramientas son secundarias y principalmente para deshacerse de la tediosidad de ciertas cosas en Java. En ruby, puedes simular trivialmente la mayor parte de lo que Spring o Guice hacen por ti en Java. Entonces, un marco completo de inyección de dependencias es esencialmente redundante en Ruby.
Dicho esto, a veces tener un marco de DI es algo agradable, ya que en última instancia, puede quitarle algo de aburrimiento al cableado. No puedo dar fe de ningún marco de DI específico de Ruby, pero conozco muchos proyectos de Ruby que finalmente se reescribieron en otro idioma (Java incluso) porque la naturaleza de los juegos hace que las cosas se vuelvan difíciles de mantener. Sospecho que esto tiene mucho que ver con que los desarrolladores se peguen un tiro en el pie con las diversas funciones de lenguaje de gran alcance. Tener un marco de DI impone un poco de estructura y modismos que pueden ayudar a prevenir esto.