If I add OptionsResolver to the constructor params, then the end user will need to inject it. But what sense does that make? Does the user need the ability to pass different implementations of that? I doubt it. But maybe that's not the proper test for whether something should be a constructor param or not.
I know what's supposed to happen: each object asks for what it needs in its constructor, and this allows testing to pass in mocks in place of the real thing.
But in this case, the only applicable interface would be an empty one, which is bad. (Unless an interface can specify the __invoke() method -- can it? Or maybe I just need to call that method something else to make the interface valid?)
@TomBZombie I sure would appreciate your thoughts on this. I still have a few things to learn.
I'm not satisfied with the way the ConfigResolver class is structured now, but I'm not sure of the best way to change it.
See the bottom of notes.md for my API thoughts so far.
If I add OptionsResolver to the constructor params, then the end user will need to inject it. But what sense does that make? Does the user need the ability to pass different implementations of that? I doubt it. But maybe that's not the proper test for whether something should be a constructor param or not.
I know what's supposed to happen: each object asks for what it needs in its constructor, and this allows testing to pass in mocks in place of the real thing. But in this case, the only applicable interface would be an empty one, which is bad. (Unless an interface can specify the __invoke() method -- can it? Or maybe I just need to call that method something else to make the interface valid?)
@TomBZombie I sure would appreciate your thoughts on this. I still have a few things to learn.