Est-ce une utilisation valide de DIP (SOLID)?

Question

Je voudrais demander si cette implémentation des classes Genotypes et Individual viole le principe d'inversion des dépendances? Si oui, comment résoudre ce problème?

Voici le code:

public interface IGenotype 
{ 
    //some code... 
} 

public abstract class AIndividual 
{ 
    // ... some code 
    public IGenotype Genotype { get; set;} // DIP likes that ! 
} 

public class Individual : AIndividual 
{ 
    public Individual() 
    { 
     // some code ... 
     this.Genotype = new Genotype(); // Is this ok in case of DIP? 
    } 
} 

public class Genotype : IGenotype 
{ 
    // ... some code 
} 

Answer 1

J'espère que cela pourrait aider (s'il vous plaît lire les commentaires)

public interface IGenotype 
{ 
    //some code... 
} 

public class Genotype : IGenotype 
{ 
    // ... some code 
} 

public class Individual 
{ 
    // Here, instead of depending on a implementation you can inject the one you want 
    private readonly IGenotype genotype; 

    // In your constructor you pass the implementation 
    public Individual(IGenotype genotype) 
    { 
     this.genotype = genotype; 
    } 
} 

// Genotype implements IGenotype interface 
var genotype = Genotype(); 

// So here, when creating a new instance you're injecting the dependecy. 
var person = Individual(genotype); 

Vous n'avez pas besoin de la classe abstraite Tremper

Answer 2

Le principe d'inversion de dépendance concerne le logiciel modules pas nécessairement classes. L'idée est qu'à la place des couches de niveau supérieur en fonction du codage des couches de niveau inférieur, il est préférable que les couches supérieures définissent l'interface de couche en fournissant une classe abstraite (un C# interface sert bien) pour les couches inférieures. mettre en œuvre et fournir les services dont la couche de haut niveau a besoin. Une erreur courante consiste à confondre ce principe avec dependency injection, où les dépendances sont fournies à une classe dépendante par un niveau supérieur, au lieu de la classe dépendante ayant besoin de les trouver et de les créer.

Il semble que vous vous interrogiez sur l'injection de dépendance, qui est "comment ma classe dépendante obtient-elle une instance de ma dépendance?" Cet exemple ressemble à ces deux classes qui appartiennent au même modèle de domaine, ce qui signifie qu'elles seraient très probablement dans le même module. Avoir une classe dépend d'une autre classe et la créer directement dans le même module est une approche raisonnable, mais le Factory pattern est plus robuste au fur et à mesure que les classes évoluent.