Как интерфейс играет роль в внедрении зависимостей конструктора

Question

Я пытаюсь понять концепцию внедрения зависимости на основе конструктора.Я видел несколько примеров кода constructor based dependency injection с использованием интерфейсов.В фрагменте кода я видел, что конструктор класса обслуживания ожидает параметр типа interface, но при создании объекта класса обслуживания передается экземпляр класса, который реализует этот интерфейс.Так почему же во время выполнения тип класса приводится к типу интерфейса или есть что-то еще?Что происходит за кулисами?

Позвольте мне поделиться некоторыми примерами кода -

Интерфейс -

Простой интерфейс для реализации

namespace constructor_di
{
    interface IRepoInterface
    {
        string test();
    }
}

Репозиторий -

Интерфейс реализации класса репозитория

namespace constructor_di
{
    class Repository : IRepoInterface
    {
        public string test()
        {
            return "Test String";
        }
    }
}

Сервис -

Класс обслуживания, ожидающий, что IRepoInterface будет передан при создании объекта

namespace constructor_di
{
    class Service
    {
        private readonly IRepoInterface _repo;

        public Service(IRepoInterface repoInterface)
        {
            _repo = repoInterface;
        }
    }
}

Запуск программы -

Создание здесь экземпляра класса Service

namespace constructor_di
{
    class Program
    {
        static void Main(string[] args)
        {
            Service obj = new Service(new Repository());
        }
    }
}

Answer 1

Интерфейс - это контракт с определенной в нем подписью какого-либо участника.Это не имеет ничего общего с их реализацией.Таким образом, любой класс, реализующий интерфейс, выполняет контракт, и, следовательно, его объект является допустимой заменой для проверки типа этого типа интерфейса или классов, реализующих этот интерфейс.

Example-

using System;

interface IRepoInterface
{
    string test();
}

class BaseRepository : IRepoInterface
{
    public string test()
    {
        return "Test String in implementing class";
    }
}

class ChildRepository : BaseRepository
{
    public string SomeFunctionName()
    {
        return "Test String in child class";
    }
}

public class Program
{
    public static void Main()
    {
        ChildRepository repo = new ChildRepository();
        Console.WriteLine(repo is ChildRepository);
        Console.WriteLine(repo is BaseRepository);
        Console.WriteLine(repo is IRepoInterface);
    }
}

In вышеФрагмент кода, класс BaseRepository реализует Интерфейс, а класс ChildRepository расширяет класс BaseRepository.

Таким образом, любой объект класса ChildRepository пройдет проверку типов для ChildRepository, BaseRepository и IRepoInterface.

Answer 2

Внедрение зависимостей через конструкторы - отличный способ минимизировать тесную связь и повысить тестируемость вашего кода.Вам даже не нужно использовать контейнер внедрения зависимости;в своем корне композиции вы указываете, какие классы, реализующие эти интерфейсы, будут использоваться, и внедряете их в своих потребителей.

Класс, имеющий зависимость, выраженную в качестве контракта, тогда заботится только о поведении, указанном в контракте.,Он не заботится о деталях реализации.

Это позволяет улучшить базовое поведение с помощью декораторов, которые реализуют тот же интерфейс и добавляют дополнительные функциональные возможности без изменения самой предыдущей / базовой реализации.

Ив модульных тестах вы можете изолировать зависимости, используя некие ложные или фиктивные реализации, и проще протестировать самого потребителя.

Что касается вашего вопроса:

Так как жево время выполнения тип класса приведен к типу интерфейса или есть что-то еще?Что происходит за кулисами?

Если класс реализует интерфейс, его можно внедрить в класс потребления без приведения.Компилятор гарантирует, что вы взаимодействуете только с членами, предоставляемыми интерфейсом.

Дополнительная информация: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/