In the realm of object-oriented programming (OOP), dependency injection (DI) emerges as a cornerstone technique for managing dependencies within so...
For further actions, you may consider blocking this person and/or reporting abuse
I think is useful in some situations (as any other pattern in any other situation) Combining Dependency Injection (DI) with the Singleton pattern can make testing easier by mocking dependencies and focusing on specific outputs. It's like having a single, global instance of something that's needed everywhere, but with the flexibility to swap it out for testing. This setup makes it simpler to test individual parts of your code without worrying about the whole system. Plus, it keeps your code clean and modular, making it easier to maintain and extend
Worst design pattern by my opinion.
So, in your opinion, what design pattern is suitable?
I'm okay with others but this one really grinds me gears. 😁
@stefanak-michal can you tell me why it is the worst design pattern?
Let me clarify, it's just my personal opinion. For me it feels like lazyness. It adds extra layer of abstraction which can affects the performance. I know what the object needs so I'll give to it, I don't want to relay on some magic to do its job.
You can do dependency injection without abstraction. All it is is clean declaration of who owns what and who needs what. Further, it can be done right there at compile time so there isn't even the bootstrap startup time.
aha, I also don't like DI....
Good article, thanks!
If you're interested in typescript dependency injection with a bit of magic - check out Clawject dev.to/artem1458/clawject-simplify...
Thank you, I will definitely look
That's such a weird picture at the beginning. Looks like an old AI image generator because of how awful the words look and the fact that the needle is in a nonsense spot.
Yes, I made that picture with artificial intelligence, I just wanted it to look like dependency injection
I suppose it's a good representation of how it turns out when the junior dev team is unsupervised.
What distinguishes dependency injection from subscription patterns like event handlers?
Almost everything. Dependency injection is about getting particular code modules available to the system via abstraction. Once they're bound, they largely stay that way until the system is reconfigured (for example to change an email provider, using the author's example).
Event handlers are about getting particular types of data into the system continuously during execution, and the event source is often bound and unbound throughout the runtime of the system.
Just to get it right: Assume your "system" is the actor, doing a particular job. With DI it get´s access to external code modules that it can call to do a job (like sending an email).
With an event handler, an external module (like the mailing system) can announce an event function to the "system". In case, the "system" want´s to send an email, it checks if there is an event function installed and calls it with the predefined parameters.
So, the main difference seems to be the knowledge of external dependencies, while the effect is very similar. Or did I get something wrong?
Interesting, thanks for the explanation, I didn't know much about subscription patterns
DI isn't subscription at all. With DI, the one with the handle to the other object is in control of when it snags things. With subscription patterns it's inverted -- the other stuff, which the code currently in control is calling to, has no idea what's subscribed to it.
DI might be "one instance, many places each method can be called from" where subscription is "method called from one place (internally), trigger everyone else to call their methods."
Hehe the AI cover
yep