On larger code bases it can help a lot. You get to a point where you need that config object over in some random function and you start weaving it through constructors. At which point a simple DI system really appeals.
DI code also tends to be more pleasant to test in my experience since it promotes loose coupling.
And you should probably avoid situations where you suddenly need config objects in 'random places'. This could be a symptom of chaotic API design. But then again, whatever works for you.
Comments
On larger code bases it can help a lot. You get to a point where you need that config object over in some random function and you start weaving it through constructors. At which point a simple DI system really appeals.
DI code also tends to be more pleasant to test in my experience since it promotes loose coupling.
I believe there are other ways:
http://commandcenter.blogspot.com/2014/01/self-referential-f...
And you should probably avoid situations where you suddenly need config objects in 'random places'. This could be a symptom of chaotic API design. But then again, whatever works for you.
Quite the contrary as repeatedly experienced in Java land.