Dependency Injection - number of injected parameters smells

Question

I was tonight thinking what it tells about design and architecture of classes with many injected objects. I am taking into consideration setter and constructor injection specifically.

Setter injection proponents always use an argument of constructor injection complexity in opposition to setter simplicity especially in cases where the number of parameters in constructor grows, but that is a different topic.

I would think, that a large number of injected parts suggest a breach of single responsibility of the object. There could be special snowflakes, but in general good metric, I think.

Now how to fight it especially in cases where the vertical depth of constructors is bigger than let's say 3?

I am thinking about some guidance\rules to fight these cases.

Explanation: Vertical Depth

Let's say that we have some complex architecture, where some class UniversalHelper/IUniversalHelper is created early in the root or close to the root and the instance is permeating throughout the graph deeper and deeper. I do not consider loggers as such objects, they do have specific purpose must permeate through whole architecture, but something like universal data access. It feels that something like specific data managers for specific data access cases should be used and then more general object UniversalHelper would not be permeating through the architecture, its vertical depth would be limited instead horizontal depth would grow in one specific point, where UniversalHelper would be used to create specific data managers, objects with refined, more constrained or limited responsibility towards single responsibility goal.

Obviously, where is allowed to one universal object to permeate whole architecture, sooner or later there will be two, three, five :). It is logical because it feels to seasoned developers on the given project as a useful, right and tested way of life and for new developers joining specific project it is a sign, it was always done this way, if you do that in the same manner, it has higher probability to pass code review from seasoned colleagues on the project...

Answer 1

You can, in principle, do dependency injection in two ways: By passing all the injected classes to the constructor creating an instance, or by having some global method that provides all classes that could be injected to anyone who needs it. (I'm sure someone can find a third way :-)

The latter method means an instance just has to grab exactly those injected classes that it needs itself, and that it therefore knows about.

The first method has the problem that if the instance has dependencies (if it creates other instances), then it has to pass the right injected classes to the constructors of these instances. And these might be injections that the instance doesn't care about and shouldn't have to care about.

Worst case: You add a class I to be injected to instances of one class A. So then any constructor creating those instances of A needs to pass that injection I. So all classes B whose instances create instances of A need I. So all classes C whose instances create instances of B need I. And so on.

That's the reason why I very much prefer "every man for himself": Any instances needing an injection should get it themselves from somewhere.