web-dev-qa-db-fra.com

Doit-on utiliser l'injection de dépendance même si la classe n'est utilisée qu'une seule fois?

Au cours d'une révision de code, j'ai commencé à avoir un peu de dilemme quant à savoir si utiliser l'injection de dépendance ou non. J'aimerais entendre vos réflexions, car il s'agit en quelque sorte d'un thème permanent et cela aiderait également dans les futures révisions de code.

Avant de commencer, je tiens à dire que d'après mes connaissances, DI est principalement utilisé pour la gestion des dépendances et des tests unitaires meilleurs et beaucoup plus faciles (corrigez-moi si je me trompe, s'il vous plaît).

Voici maintenant le scénario:

Il s'agit de la classe qui sera utilisée comme dépendance une seule fois et probablement pour de bon. Cela signifie qu'il restera ainsi pendant un certain temps et aucune autre classe ne l'utilisera.

La raison en est que c'est une refactorisation d'un code hérité et qu'il n'y avait pas grand-chose à faire, mais pour le séparer dans une autre classe, au moins comme une première bonne étape, pour suivre le SRP .

En outre, une autre chose est que l'hypothétique doSomethingImportant () frappe la base de données.

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

Sur la base de ces informations, pensez-vous qu'il est correct de renouveler la dépendance dans l'autre classe au lieu d'utiliser DI puisque:

L'argument de gestion des dépendances tombe en quelque sorte car il ne sera utilisé qu'une seule fois.

&

Les tests unitaires tombent également car je préfère faire un test d'intégration ou d'acceptation pour voir comment la méthode interagit avec la base de données dans une application réelle.

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

   public Object doSomethingImportantUsingDependency()
   {
      ...
   }
}

J'étais personnellement enclin à faire de l'ID parce que c'est considéré comme une bonne pratique, mais pendant une seconde, j'ai eu l'impression de suivre aveuglément les règles et de ne pas y réfléchir car il y a toujours des exceptions à la règle.

Que pensez-vous de ceci? J'adorerais entendre.

PS: Je ne pense pas que ce soit une question générique "quand devrais-je utiliser DI" car elle est très spécifique à cette situation particulière lorsque les tests unitaires ne sont d'aucune utilité et que la classe va être utilisé qu'une seule fois donc il n'est pas nécessaire de le centraliser pour la gestion des dépendances (même si c'est une bonne pratique en général).

c#.netunit-testingdependency-injectiondependency-management
15
AvetisG

En C #, il est trivial de fournir une injection de dépendance facultative sans vous coupler trop étroitement à votre dépendance:

public class SomeOtherClass {
    private readonly ISomeClass _someClass;

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

(ou vous pouvez rendre les constructeurs explicites si votre entreprise n'aime pas les paramètres par défaut)

D'après mon expérience, "oh nous n'en aurons jamais besoin d'autre" est naïf. Changements commerciaux. Changements technologiques. Rendre les dépendances flexibles.

Et ce genre de chose trouve le bon équilibre entre la convivialité (oui, vous utiliserez presque toujours celle commune/par défaut) et la flexibilité (mais le ctor est là si vous en avez besoin) - le tout avec une belle ligne de code simple, tout en fournissant également un semblant de robustesse corrigeant les erreurs. C'est tellement trivial et clairement bénéfique, il n'y a aucune raison de ne pas le faire pour le cas simple/direct.

15
Telastyn

Il y a un principe de développement dans le sens de DRY et SOLID appelé YAGNI) qui est conçu pour vous aider à rationaliser vos efforts de développement pour faire avancer les choses et ne pas être paralysé par l'indécision sur quoi faire.

Si vous constatez plus tard que vous devez améliorer votre classe, vous le ferez. YAGNI dit de ne pas s'inquiéter autant à ce sujet maintenant, car vous n'aurez probablement pas besoin de dépenser cet effort supplémentaire. Faites-le, revenez-y si vous en avez vraiment besoin.

Certains disent que c'est l'opposé de SOLID mais en réalité, il s'agit de négocier tous les facteurs impliqués dans le développement, vous n'avez pas de temps ou de ressources infinis (et le code "parfait" n'est jamais à mon humble avis).

Donc ici, vous dites qu'il n'a pas besoin de complexité DI ... alors voici votre réponse. Ne le mettez pas. Passez à toutes les autres choses que vous devez faire.

11
gbjbaanb

Si vous n'appliquez pas DI tant que vous n'en avez pas vraiment besoin (pas même pour les tests unitaires), rien de mauvais ne se produira. Le code ne devient pas sujet aux erreurs, "trop ​​compliqué" ou difficile à maintenir. Et si vous décidez de refactoriser la dépendance plus tard, ce ne sera probablement pas beaucoup plus d'efforts que de le faire maintenant. C'est un cas où le principe YAGNI s'applique.

Cependant, ce que vous devez vérifier, c'est si vous êtes sûr que vous ne voulez vraiment pas pouvoir tester unitairement SomeOtherClass indépendamment de SomeClass, et si la dépendance imposée aux assemblages où SomeOtherClass et SomeClass live ne deviendront pas un problème. Si vous êtes sûr à 100% que la réponse aux questions précédentes est "oui", vous pouvez ignorer DI.

5
Doc Brown

La réponse comme la plupart des choses est "ça dépend".

Si vous souhaitez tester les fonctionnalités dans doSomethingImportantUsingDependency, vous devrez pouvoir injecter la dépendance.

Cependant, si tout ce que doSomethingImportantUsingDependency fait est un mappage de propriété à partir du résultat de votre appel de base de données, il serait pragmatique de ne pas déranger.

Si une autre classe dépend de SomeOtherClass, vous pouvez toujours injecter cette classe à la place.

0
Matthew