It does actually solve the problem that DI solves in general, because you create readers that expect the dependency to be injected into them. You still have to decide how to do the injection and that's true for all of the non-framework approaches AFAICT. With the cake pattern you still have to create an object somewhere that mixes in all of the concrete implementations. What you gain from the reader pattern is being able to limit the biolerplate to edge where the injection actually occurs.
As far as having to create a whole dummy Config for testing, that's a fair point, although the reader approach makes it easy to inject it since every reader is a function of the Config. I usually only have a small number of dependencies so it hasn't really been an issue for me. If you're mocking the dependencies each one is only one line of code, and for dependencies you don't need in the you can just use ???.
As far as having to create a whole dummy Config for testing, that's a fair point, although the reader approach makes it easy to inject it since every reader is a function of the Config. I usually only have a small number of dependencies so it hasn't really been an issue for me. If you're mocking the dependencies each one is only one line of code, and for dependencies you don't need in the you can just use ???.