Соответствует ли шаблон прототипа внедрению зависимостей?

Я читал, что при использовании внедрения зависимостей следует избегать создания объектов с new вне инжектора […].

Это верно лишь отчасти. Я покажу вам шаг за шагом, что new имеет свое место, и что вполне можно использовать new для реализации шаблона прототипа.

Начнем с очевидного: если нам нужен экземпляр типа B, то он должен быть кем-то где-то создан. Допустим, у нас есть это:

class C
{
    void Baz()
    {
        B b = new B(new A(…));
        b.Bar();
    }
}

Baz требует B для выполнения своей работы. Если мы хотим избежать new B(…), лучшее, что мы можем сделать, это удалить его из этого конкретного места в кодовой базе:

class C
{
    C(Func<B> newB) // instead of Func<B>, we could also inject a B directly
    {               // (the difference being that we would no longer control
        this.newB = newB;                        // when the B gets created)
    }

    Func<B> newB;

    void Baz()
    {
        var b = newB();
        b.Bar();
    }
}

Но B, передаваемый конструктору C, все равно должен быть где-то создан. Только теперь это где-то в другом месте.

Итак, что мы получили, избегая new? C больше не требуется иметь внутренние знания о том, как именно создать B.

Но как Func<B> newB (т.е. фабричный метод) сам создаст B без использования new? Кажется, мы не можем вечно уклоняться от new.

Чтобы прояснить этот момент, давайте перейдем к другому, очень связанному примеру, который немного ближе к вашей проблеме (реализация шаблона прототипа в контексте DI): Абстрактные фабрики, еще один шаблон проектирования. Допустим, у нас есть BFactory, единственной обязанностью которого является создание экземпляров типа B:

interface BFactory
{
    B CreateB();
}

Можем ли мы реализовать это без использования new? Попробуем так же, как описано выше:

class RedundantBFactory : BFactory
{
    RedundantBFactory(Func<B> newB)
    {
        this.newB = newB;
    }

    Func<B> newB;

    public B CreateB()
    {
        return newB();
    }
}

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

Мы можем заключить, что разумно и уместно использовать new внутри абстрактных фабрик и фабричных методов (например, в BFactory или даже newB выше), если мы не хотим, чтобы они были полностью избыточны:

class UsefulBFactory : BFactory
{
    public UsefulAFactory(Func<A> newA)
    {
        this.newA = newA;
    }

    Func<A> newA;

    public B CreateB()
    {
        return new B(newA());
    }
}

Теперь к вашему шаблону прототипа: шаблон прототипа, по сути, касается клонирования объектов. То есть все типы, реализующие ваш интерфейс IAnalysis, должны иметь возможность создавать клоны (копии) экземпляра. Как и в приведенном выше примере с абстрактной фабрикой, единственной целью вашего интерфейса является инкапсуляция некоторой формы создания объекта. В первую очередь это причина его существования, поэтому классы, реализующие этот интерфейс, не должны делегировать эту ответственность внешней стороне. Опять же, в этом случае вполне разумно использовать new:

class W : IAnalysis
{
    W(X x, Y y, …)
    {
        this.x = x;
        this.y = y;
        …
    }

    public IAnalysis CreateObject()
    {
        return new W(x, y, …);
    }
}

И последнее замечание, просто чтобы подчеркнуть и завершить мое первоначальное заявление о том, что избегать new не во всех случаях имеет смысл: обратите внимание, что в любом случае DI не следует использовать для всего.

Обычно вам нужно принять решение о том, какие типы должны обрабатываться контейнером внедрения зависимостей. Эти так называемые зависимости, или компоненты, или службы обычно абстрагируются как interface или abstract class BaseClass, так что вы, возможно, позже сможете заменить одну реализацию другой. Единственное место, где вы используете new Service(…), должно быть в корне композиции или (как показано выше) в абстрактных фабриках или фабричных методах (которые сами по себе являются зависимостями, которые будут внедряться туда, где вам нужно создавать объекты в выбранное вами время). Если бы вы щедро разбросали new Service(…) по всему коду, было бы трудно заменить одну реализацию другой.

Но совершенно нормально использовать new для создания примитивных значений и экземпляров типов значений (таких как string, TimeSpan и т. д.). Эти типы обычно не создаются контейнером внедрения зависимостей.

Я читал, что при использовании DI следует избегать конструкторов, поэтому я не совсем уверен, разрешено ли это в DI.

Это работает не так, но конструкторы — это деталь реализации реализации, и поскольку потребители знают только об абстракции, они не могут вызвать конструктор.

Но эти типы должны быть кем-то созданы. Этот кто-то является корнем композиции. Если вы используете чистый DI, вы будете вызывать эти конструкторы. Если вы используете контейнер внедрения зависимостей, контейнер вызовет конструктор от вашего имени.

Помня об этом, классы можно создавать с использованием ключевого слова new, но когда дело доходит до внедрения конструкторы, вы должны хранить это создание локально в корне композиции. Это можно сделать, определив реализацию IAnalysis внутри корня композиции. Таким образом, остальная часть приложения не должна зависеть от этого конкретного типа и его конструктора. Если вы используете библиотеку DI, эта реализация может зависеть от контейнера и вызывать его для запроса нового экземпляра.