100% this. Having worked on projects using and not using DI in several languages, I'd prefer a world in which we just say no to DI. What it offers, relative to the indirection and cognitive overhead has almost always been net negative.
Honestly, I don't know how you came from "my object needs objects A, B, and C to work" to the "it's cognitive overload". Your object still needs A, B and C to work, just with any other approach it's implicit which is spooky action at a distance in its finest and way more cognitive load.
def main:
a = ...
b = ...
c = ...
my_object = MyObject(a,b,c)
my_object.do_something()
def main:
my_object = make_my_object() # constructs my_object as above
my_object.do_something()
Magic, monkey-patching mess of dependency injection libraries is terrible.
Dependency injection as a concept is simple functional approach to imperative and OO programming.
> If a, b and c are MyObject's "dependencies", that's dependency injection.
In practice, though, at least coming from a Java/.NET background, DI would be understood as using something like a decorator/annotation/some registration mechanism to let the framework handle giving you a valid instance of the class that you're after, rather than straight up using the constructor whilst filling out the parameters manually.
While your example is technically true, it wouldn't be the answer that anyone in a programming interview (at least for those languages) might expect you to provide as an example.
That said, adopting the composition root approach in a Java project (or using a god-object for all of the services) was oddly liberating and felt way more simple than mucking about with appeasing Spring's @Autowired annotation and its finnicky nature.
The fact that most of that terminology is misunderstood simply supports that claim above. The fact that interviews are also generally silly is besides the point too. :)
Still, none of that should be a benchmark for what something is. Dependency injection is simply about injecting a dependency instead of using it as a side-effect. You can achieve that in many ways, and the simplest is just to pass it in.
if __name__ == "__main__":
a = os.getenv("foo")
b = get_from_somewhere()
c = "some_hardcoded_variable"
my_app(a, b, c)
My original reply was in response to "please don't make Python Java", where that flavor of spooky action DI seems to be common.
To your original question: `what do I suggest`. I point to the authors example:
di = Di()
@di.register('A')
class A:
def __init__(self, di: Di):
pass
def action(self):
print("Hi from A")
@di.register('B')
class B:
def __init__(self, di: Di):
self._di = di
self._a = None
def run(self):
self.get_a().action()
def get_a(self):
if self._a is None:
self._a = self._di.get('A')
return self._a
@di.override('A') # replace class A definition with a new one
class C:
def __init__(self, di: Di):
pass
def action(self):
print("Hi from C")
di.get('B').run() # prints "Hi from C"
di.remove('B') # removes the B dependency from the registry
How about:
class A:
def __init__(self):
pass
def action(self):
print("Hi from A")
class B:
# A is default for some reason
def __init__(self, a=A()):
self._a = a
def run(self):
self._a.action()
class C:
def __init__(self):
pass
def action(self):
print("Hi from C")
if __name__ == "__main__":
if os.getenv('ENV') == "PROD":
a = A()
b = B()
# test/non-prod/whatever version
else:
a = A()
b = B(C())
In the proposed example, I would go in, read it (assuming I know to even look for this non-idiomatic use of the language) and then read through this code to figure out what should have just been an argument passed to B.
Which leads back to my original question: what is this buying me over dunder main or handing some arguments? In terms of cost, I have to understand something and walk through the code to understand something that could have been done more simply and more explicitly without this DI pattern.
Edit: formatting
If you are using something like Java or C++ then it's easy to see the benefits (some C++ developers would disagree though, read https://accu.org/journals/overload/25/140/pamudurthy_2403/).
More code = more cognitive overhead