3 ms·
It really depends. In a large desktop project of ours (we can call it "monolith"), we had manual construction of dependencies, and it quickly became a hard to u
by kgeist 5y ago
It really depends. In a large desktop project of ours (we can call it "monolith"), we had manual construction of dependencies, and it quickly became a hard to understand spaghetti mess. A clean declarative DI framework like in the Java world would save us a lot of trouble. On the other hand, we now mostly write small microservices in Go, and manual DI is more than enough.
Passing interfaces to functions directly instead of at construction time sounds like a leaky abstraction, because I as client should not care that some function relies on another function as an implementation detail. Functional languages solve it with currying and in this context I don't see semantic difference between currying and saving a dependency in a class/struct in OOP languages, they're analogous.
- gpderetta 5y agoIn a large server project of ours, we had a sophisticate declarative DI framework, and it quickly became a hard to understand spaghetti mess of config files. A clean manual construction of dependencies would have saved a lot of troubles. Snark aside (but the sentence above is really what happened at $PREVIOUS_JOB), I think there is value in assigning dependencies declaratively, but I think it is better done in a proper programming language (with IDE support, compile-time error checking, proper parametrization and escape to procedural code, testing, etc.), not in an xml file (and no, json or yaml are not better).