If I am writing up a class with more than 1 constructor parameter like:
class A{
public A(Dependency1 d1, Dependency2 d2, ...){}
}
I usually create a “argument holder”-type of class like:
class AArgs{
public Dependency1 d1 { get; private set; }
public Dependency2 d2 { get; private set; }
...
}
and then:
class A{
public A(AArgs args){}
}
Typically, using a DI-container I can configure the constructor for dependencies & resolve them & so there is minimum impact when the constructors need to change.
Is this considered an anti-pattern and/or any arguments against doing this?
This does open the door for it appearing that your dependencies are optional. By having properties for each of the dependencies for your AArgs class, someone can think they only need to fill in Dependency1, and everything will work as expected.
By explicitly listing all of your dependencies individually, you give a clear contract about what is needed for your class to function. If you have so many dependencies that the constructor is cumbersome, that should be considered a smell, as your class may be doing too much.