Это допустимое использование DIP (SOLID)?

Question

Я хотел бы спросить, нарушает ли принцип внедрения классов Genotypes и Individual? Если да, то как это исправить?

Вот код:

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

Я надеюсь, что это может помочь (пожалуйста, прочитайте комментарии)

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

Вам не нужно абстрактный класс DIP

Answer 2

Принцип инверсии зависимостей относится к программному обеспечению модули не обязательно являются классами. Идея состоит в том, что вместо уровней более высокого уровня в зависимости от того, как кодируются слои нижнего уровня, лучше, чтобы более высокие уровни определяли интерфейс слоя, предоставляя абстрактный класс (C# interface служит для этого красиво) для нижних слоев внедрять и предоставлять услуги, требуемые для уровня высокого уровня. Распространенная ошибка заключается в том, чтобы смутить этот принцип с dependency injection, где зависимости предоставляются для класса, соответствующего более высокому уровню, вместо того, чтобы быть зависимым классом, нуждающимся в их поиске и создании.

Похоже, вы спрашиваете об инъекции зависимостей, а именно: «Как мой зависимый класс получает экземпляр моей зависимости?» Этот пример выглядит как эти два класса, которые относятся к одной и той же модели домена, что означает, что они, скорее всего, будут в одном модуле. Наличие класса зависит от другого класса и его создания непосредственно в одном модуле - разумный подход, однако Factory pattern более устойчив по мере развития классов.