I don't think it should. If you have a small cluster of objects where you
can manage the dependencies yourself, you can compose larger objects from
them and manage the dependencies the same way. By doing so, you'll get an
object that is simpler from the outside than it's parts in the inside, and
you'll need to solve the smaller problem again. In other words we shouldn't
write large software, but compose large software from smaller ones. But the
same can be done with objects (that's why I'm not a big fan of microservices
despite they solve this problem similarly).
If you have a flat structure (where objects don't form higher level
abstractions) and everything needs to know about everything else, then the
DI container will make it easier to work with this structure. But I don't
think this is the right way to organize a software.
Yes, that makes sense....
1. Blocks (i.e. anonymous functions) means that one needs not necessarily
implement a /Class/ (MovieFinder), in order to vary alternative behavior,
unlike Java (before 8).
2. If one does want a number of "finders" (as Classes), then one will
typically see one "injected" (constructor or method injection), where each
understands some common "find" message.
Is the real question for 2 above, "what (or who) decides" which will be
injected?
Finder is just an illustration of the problem, that finder class can have much more behavior in a real example, such as a DAO or a Repository would have, and blocks could't be used properly to deal with that.
cheers,
Vitor
Locked
