Dependency Injection Explained in 7 Minutes

Beautifuly explained, clear as water! keep it up!! I think dependendy injection is one of the most important concepts in programming!

The power of Python's duck-typing leads really well into dependency injection.

Just pass an object that has the required properties/methods, and done. No need to subclass from an esoteric BaseSomethingClass first.

Deja vu, You have recorded almost the same video again. Arjan it's time to go deeper into more advanced examples.

Agree your codebase gets such an improvement when you start using dependency injection.

This time I felt like I've already seen this video. You should talk about an auto wiring DI library like kink

I prefer SMTP as my email sender. Works every time, regardless of how a customer has configured his email server.

"Dependency injection", as explained here, is probably the most simple OO design pattern. In OO, it is called the Strategy Pattern. You hide the details of an algorithm behind an (abstract) interface. The user of the strategy only knows the abstract interface, each implementation of the Strategy interface knows only the details it needs.

I don't understand why people wanted to change the name. The name "Strategy Pattern" has been in wide-spread use for 30 years. I guess people like re-inventing the wheel.

That is no critique on Arjan, he didn't coin "dependency injection". I thank him for this video, I never understood what people meant with DI. I thought it was some complex trick like the "Curiously Recurring Template" pattern. Which is similar to DI but achieves lightning fast execution & minimal memory footprint, at the cost of long compile times.

I don't get the real advantage of it .The lines of code you reduce in the first class you have to put them in an other file, so you end with the same (probably more) lines, more files and dependencies. I would really like to understand the advantages of it to apply it more naturally.
Thanks in advance

Recently did something like this for work. But used a general email sending function that takes in smtp type, port etc for different email providers.

I am bit confused, since when we have to inherit explicitly from Protocols? Your Smtp, SendGrid and MailChimp classes all inherit from EmailService. Or is this just to show that those classes implements the protocol?

Postmark

is decency injection only applicable on Classes?

I've started using Resend for all of my projects after many years of using Sendgrid and really enjoy it.

These are the best videos!!

There's an awesome third party library called Dependency Injection, it's so good to apply this principle to any python project

I've been doing this but had no idea it was a design pattern.

Reupload? I swear I've watched this before.

From my experience, most email services, from a back-end use scenario, feel the same. Where they really shine is how they interact with other providers. For example, emails sent through MailChimp may have different headers or be easier to format.

Don't get confused when talking to Java programmers about DI. Over there, it generally means "magically inferring which service to use".

Hey Arjan, thank you for your work from Spain. Would be great if you create a video with your top python books "to improve your python skills to another level", thank you!

Why do you use Protocols if you're going to subclass that anyway? Doesn't it defeat the purpose of Protocols (structural subtyping) in the first place?

So in this case, how the email service specific arguments are going to be handled? For example the attachment argument? First we are going to create an instance of email service, pass the arguments to it and then use it to create an instance of EmailSender to actually send the email?

I know only mailchimp. Now I found out about sendgrid as well.

Yes it's a great pattern. To actually manage and reduce dependencies you need also consider where to place your abstract classes and interfaces.

Can we see the files email_service and services? You put code there and never showed them

In the after version, do we even need the EmailSender anymore? It does nothing but redirects the send call with the same parameters to the EmailService. We could just use the EmailService directly for that.

I’m confused between the factory pattern and dependency injection. I watched both your videos. Is it the same?

Hello Arjan, great video as usual! I have a question why do you inherit from the protocol in a class which implements one? It's the second video in which I can see this, whereas in ABC vs Protocol you pointed out that it is not needed (duck typing) and also decouples the one who implements from the one who requires. Is there any reason for that? Thank you in advance for the response.

The emailSender class here is not needed imo. A better approach (imo) would be to use a common interface on the sender classes, and use DI to pass the relevant sending class to the interface object. Then just call send on the interface.

One of the surprising things I encountered when I moved from Java to Python was the heavy usage of the service locator pattern.

A typical example is Flask's "request" and "d". It is still widespread in Python to put a dependency or an accessor to a dependency in the global context and reference it inside a component. Of course, Python has enough flexibility to manage tests of such less decoupled codes. However, I have always believed that clear decoupling using DI is cleaner and more straightforward.

FastAPI's DI is handly but covers only part of the DI commonly practised in Java. FastAPI supports only DI in the "request" scope. But DI frameworks in Java, like Spring, support other scopes, including the "application" scope.

The lack of DI containers supporting the application scope is why people must repeat "app.include_router(...)" etc., to construct big applications. DI realises IoC (inversion of control) at the component level. However, you still need to control the construction of an application (injection of dependencies), as demonstrated in this video.

The automated construction of applications using DI and CoC (convention over configuration), which is widely used in Java, is something we should consider in Python as well.

we are using sendgrid in our project and your video on this really helps. thanks a ton!

How will it work if I need to pass an attachment? I still need to change send_email for all of my classes

Thanks for the great video. I understand that this is a bit of a contrived example but can you explain why you use an EmailSender class at all when it only wraps a method of the service object that is passed to the initialiser? In other words, why not just call the send_email method directly?

I'd really like a few more videos on this topic -- it seems really clever and useful but I don't totally understand it

Thanks really helpful. In this example though I couldn't see how variations in the email service protocols were catered for. The send_email method didn't show an indication of the different logic needed for different services.

We use SparkPost as our primary sending service for most critical things like invoices

hmmmm, is this actually just Strategy Pattern??

Thanks Arjan

Thank you Arjan! Clear, concise, and to the point. I now know Dependency Injection!

Great example.

Isn't using a mutable argument in Python a ROOKIE MISTAKE?

To answer your question about which email service, I'm using mailjet

I would have banged my head against a wall if not for this video.
A lot of people try to get away by just using big words. This is the first video not to do that.

Simply passing an argument into a method is not dependency injection. It's passing arguments to methods, something every programmer has done since the start of time. Similarly, using an interface or abstract protocol is not dependency injection. That's simply coding to an interface and has nothing to do with dependency injection. It's no wonder so many people are confused about the term when so many tutorials about it get it wrong.

How I hate __init__, self, classes and of course dependency inversion/injection in the code where they don't need at all. They must be used in sending emais where 10+ types of sending and 10+ different services and users that uses that sendings. In all another cases please people uses just def and modules in Python, matherfucka without classes and that oop and solid bullshit

Great video. Thanks Arjan.