¿Se debe usar Inyección de dependencia incluso si la clase se usa solo una vez? [duplicar]

14

Durante una revisión del código, comencé a tener un pequeño dilema en cuanto a si utilizar la inyección de dependencia o no. Me gustaría escuchar sus opiniones, ya que este es un tema continuo y también ayudará en las futuras revisiones de código.

Antes de comenzar, quiero decir que a partir de mi conocimiento, DI se usa principalmente para la gestión de dependencias y, por lo tanto, es más fácil hacer pruebas de unidad (corríjame si me equivoco).

Ahora aquí está el escenario:

Esta es la clase que se usará como una dependencia solo una vez y probablemente para bien. Lo que significa que permanecerá así por un tiempo y ninguna otra clase lo utilizará.

La razón es que se trata de una refactorización de un código heredado y no había mucho que hacer sino separarlo en otra clase, al menos como un buen primer paso, para seguir SRP .

Además, otra cosa es que el hipotético doSomethingImportant () llega a la base de datos.

public SomeClass
{
   public Object doSomethingImportant()
   {
      ...
   }
}

En base a esa información, ¿cree que está bien aumentar la dependencia en la otra clase en lugar de usar DI desde:

El tipo de argumento de administración de dependencias se cae ya que solo se usará una vez.

&

Las pruebas de unidad también se caen , ya que prefiero hacer una prueba de integración o de aceptación para ver cómo el método interactúa con la base de datos en una aplicación de la vida real.

public SomeOtherClass
{
   private readonly SomeClass _someClass = new SomeClass();

   public Object doSomethingImportantUsingDependency()
   {
      ...
   }
}

Personalmente me incliné a hacer DI porque se considera una buena práctica, pero por un segundo sentí que estaba siguiendo cegadoramente las reglas y no lo pensé, ya que siempre hay excepciones a la regla.

¿Qué piensas de esto? Me encantaría escuchar.

PS: No creo que esta sea una pregunta genérica de "cuándo debo usar DI" porque es muy específica para esta situación en particular cuando las pruebas unitarias no sirven y la clase se usará solo Una vez, no es necesario centralizarlo para la gestión de la dependencia (aunque es una buena práctica en general).

    
pregunta AvetisG 08.04.2015 - 17:23
fuente

4 respuestas

12

En C # es trivial proporcionar una inyección de dependencia opcional sin unirte demasiado a tu dependencia:

public class SomeOtherClass {
    private readonly ISomeClass _someClass;

    public SomeOtherClass(ISomeClass dependency = null) {
        _someClass = dependency ?? new SomeClass();
    }
}

(o puede hacer que los constructores sean explícitos si a su empresa no le gustan los parámetros predeterminados)

En mi experiencia, "Oh, nunca necesitaremos otro" es ingenuo. Cambios en los negocios. Cambios tecnológicos. Hacer dependencias flexibles.

Y este tipo de cosas encuentra el equilibrio correcto entre la facilidad de uso (sí, casi siempre usará el común / predeterminado) y la flexibilidad (pero el ctor está ahí si lo necesita), todo con una línea simple y agradable de código, mientras que también proporciona cierta apariencia de corrección de errores robustez. Es tan trivial y claramente beneficioso, no hay razón para no hacerlo en el caso simple / directo.

    
respondido por el Telastyn 08.04.2015 - 17:35
fuente
10

Hay un principio de desarrollo en las líneas de SECO y SÓLIDO llamado YAGNI que está diseñado para ayudar a agilizar sus esfuerzos de desarrollo para hacer las cosas y no paralizarse con la indecisión sobre qué hacer.

Si luego descubre que necesita mejorar su clase, entonces lo hará. YAGNI dice que no se preocupe tanto por esto ahora porque probablemente no tendrá que gastar ese esfuerzo extra. Hágalo, vuelva a él si realmente lo necesita.

Algunos dicen que es lo contrario de SOLID, pero en realidad se trata de intercambiar todos los factores involucrados en el desarrollo, no tienes tiempo ni recursos infinitos (y el código "perfecto" nunca es IMHO).

Entonces, aquí dices que no necesita complejidad DI ... así que ahí está tu respuesta. No lo pongas. Pasa a todas las otras cosas que tienes que hacer.

    
respondido por el gbjbaanb 08.04.2015 - 17:41
fuente
5

Si no aplica DI siempre que no la necesite (ni siquiera para la prueba de unidad), no ocurrirá nada malo. El código no se vuelve propenso a errores, "demasiado complicado" o difícil de mantener. Y si decide refactorizar la dependencia más tarde, probablemente no será mucho más esfuerzo que hacerlo ahora. Ese es un caso donde se aplica el principio YAGNI.

Sin embargo, lo que debe comprobar es si está seguro de que realmente no desea poder realizar la prueba unitaria SomeOtherClass en forma aislada de SomeClass , y si la dependencia impuesta en los ensamblajes donde SomeOtherClass y SomeClass live no se convertirá en un problema. Si está 100% seguro de que la respuesta a las preguntas anteriores es "sí", entonces puede ignorar DI.

    
respondido por el Doc Brown 08.04.2015 - 20:25
fuente
0

La respuesta como la mayoría de las cosas es "depende".

Si desea realizar una prueba unitaria de la funcionalidad en doSomethingImportantUsingDependency , entonces deberá poder inyectar la dependencia.

Sin embargo, si todo lo que doSomethingImportantUsingDependency hace es un mapeo de propiedades del resultado de su llamada a la base de datos, sería pragmático no molestar.

Si alguna otra clase depende de SomeOtherClass , entonces siempre puedes inyectar esa clase.

    
respondido por el Matthew 08.04.2015 - 17:37
fuente

Lea otras preguntas en las etiquetas