software programming patrones los lista historia diseño basado antipatterns antipatrones antipatron language-agnostic dependency-injection anti-patterns

language agnostic - programming - Inyección de dependencia mejores prácticas y anti-patrones.



patrones y antipatrones de software (6)

Soy relativamente poco experto en inyección de dependencia, y me gustaría aprender algunas de las mejores prácticas y antipatrones para usar y evitar, respectivamente, al usar DI.



Descubrí que cuando veo una violación de la Ley de Demeter, es un indicio de que podría querer una inyección de dependencia.

Por ejemplo:

void doit() { i += object.anotherobject.addvalue; //violation of Law of Demeter }

A veces insinúa que podría querer que la dependencia inyecte otro anotherobject .


En mi opinión, el libro Dependency Injection de Dhanji Prasanna es una lectura obligatoria para los diseñadores de software, tanto principiantes como expertos. Trata directamente con sus preguntas de DI.



Mi regla básica sobre cuándo usar DI es que inyectaré entre capas, así que entre mi controlador y el dao sería una capa, así que puedo inyectar, así que si quiero burlarme de una capa puedo hacerlo.

Creo que usar DI dentro de la misma capa no es una buena idea, principalmente porque la capa debe estar estrechamente unida, ya que están relacionadas, a menos que tenga una historia de usuario que la haga útil.

Por ejemplo, si su DAO puede estar en computadoras separadas, entonces es posible que tenga que simular que son de una capa, pero use DI para cambiar realmente entre una máquina y máquinas separadas. Luego, el desarrollador puede hacer todo en una máquina y debería funcionar en máquinas separadas.

Pero, a menos que exista una necesidad apremiante, creo que la DI dentro de la misma capa es una complicación innecesaria.


Realmente disfruté este artículo con respecto a DI, ya que está dirigido a personas que no tienen mucha experiencia en DI, o que ni siquiera saben qué es.

https://mtaulty.com/2009/08/10/m_11554/

¿Qué es la unidad?

It’s a “dependency injection container”.

Ahora, en ese momento, un grupo de personas que lean esto dirán "Sí, lo sabemos y ya lo estamos utilizando por las razones A, B, C o hemos elegido no usarlo por las razones X, Y, Z" y Me imagino que un montón de otras personas podrían decir;

“Huh? What’s a dependency injection container?”

Este post es para las últimas personas, no pretende ser exhaustivo, pero espero que tampoco sea del todo inútil :-)