Ist dies eine gültige Verwendung von DIP (SOLID)?

Question

Ich würde gerne fragen, ob die Implementierung der Klassen und Individual das Dependency Inversion Prinzip verletzt? Wenn ja, wie repariere ich das? Hier

ist der 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

Ich hoffe, das helfen könnte (bitte die Kommentare lesen)

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); 

Sie brauchen nicht die abstrakte Klasse

DIP

Answer 2

Dependency Inversion-Prinzip befasst sich mit Software Module nicht unbedingt Klassen. Die Idee ist, dass anstelle von höheren Ebenen, abhängig davon, wie untergeordnete Ebenen codiert werden, es für die höheren Ebenen besser ist, die Ebenenschnittstelle zu definieren, indem eine abstrakte Klasse (eine C# interface dient dies nett) für die unteren Ebenen zu Implementieren und Bereitstellen der Dienste, die die Schicht auf hoher Ebene benötigt. Ein häufiger Fehler ist es, dieses Prinzip mit dependency injection zu verwechseln, wo die Abhängigkeiten einer abhängigen Klasse durch eine höhere Ebene zur Verfügung gestellt werden, anstatt dass die abhängige Klasse sie finden und erstellen muss.

Es scheint, als ob Sie nach Abhängigkeitsinjektion fragen, die lautet: "Wie bekommt meine abhängige Klasse eine Instanz meiner Abhängigkeit?" Dieses Beispiel sieht aus wie diese zwei Klassen, die zu demselben Domänenmodell gehören, was bedeutet, dass sie sich sehr wahrscheinlich im selben Modul befinden. Eine Klasse von einer anderen Klasse abhängig zu machen und sie direkt innerhalb desselben Moduls zu erstellen, ist ein vernünftiger Ansatz, jedoch ist die Factory pattern robuster, wenn sich die Klassen weiterentwickeln.