Конструкторы + Инъекция зависимостей

Question

Если я пишу класс с более чем одним параметром конструктора, например:

class A{
    public A(Dependency1 d1, Dependency2 d2, ...){}
}

Я обычно создаю тип "держатель аргумента", например:

class AArgs{
    public Dependency1 d1 { get; private set; }
    public Dependency2 d2 { get; private set; }
    ...
}

и затем:

class A{
    public A(AArgs args){}
}

Как правило, используя DI-контейнер, я могу настроить конструктор для зависимостей и разрешить их, и, таким образом, при изменении конструкторов будет минимальное влияние.

Считается ли это анти-паттерном и / или какими-либо аргументами против этого?

Answer 1

Это откроет дверь, поскольку кажется, что ваши зависимости необязательны . Имея свойства для каждой зависимости для вашего класса AArgs, кто-то может подумать, что ему нужно только заполнить Dependency1, и все будет работать так, как ожидается.

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

Answer 2

Марк Симанн написал в блоге об этом.

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

Answer 3

Ну, я бы не стал даже называть это анти-паттерном, но если разработчику нужно внести изменения в вашу кодовую базу, было бы сложно понять, что нужно конструктору, так что «Просто чтобы быть безопасным» msgstr "они могли бы просто передать все объекты зависимостей в конструктор. Хлоп! Это одна из тех абстракций, которыми можно злоупотреблять.

Answer 4

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

Если ваш класс владельца зависимостей AArgs обычно имеет несколько членов (скажем, 3 или меньше), то это не проблема.