Skip to content

Explain IoC Container like I'm Five

github logo ・1 min read  

Hi everyone! I'm a .Net developer and I've been trying to get my head around StructureMap and IoC containers in general recently. I understand what dependency injection is, and I know how to use interfaces to make code more testable and extensible.

What exactly is an IoC container though? I welcome answers from anyone, not just other .Net developers 😁

twitter logo DISCUSS (11)
markdown guide

If you don't use IoC container, how do you instantiate objects? Somewhere in the area that starts the application, you would define how to set up the object right?

For example you have IAddProduct. You pass it to the ProductController as constructor argument. The AddProduct concrete class needs IGetUOM. So to create IAddProduct maybe somewhere in your code you have generateIAddProduct that instantiate GetUOM, then instantiate AddProduct, then return it.

IoC container makes this object generation simpler. You tell it if someone ask for IAddProduct, give them AddProduct. You tell it about IGetUOM too, and the other classes and interfaces. Later when something asks the IoC container to generate IAddProduct, it will automatically inspect that AddProduct needs IGetUOM, generates GetUOM, use it to create AddProduct, and then give the complete item to the asker.

If you are interested to learn more about dependency injection, there is a book called Dependency Injection. It's really good!


Thank you so much for your clear and accessible explanation! It's not easy explaining these things I know but thank you for having empathy for me in your response 😄


I have recently tried to explain IoC to my co-workers, and I discribe it as the magical thing that make dependency injection work, without us doing anything but focusing on writing new features. It's automagical.

Before I knew about IoC, I wrote my own new statements and building the dependency tree manually. Sometimes, that tree got huge and if I needed to change some dependency, all my trees had to be updated. IoC takes care of all that stuff at runtime.


It's not a bad thing to initially write your own dependency tree manually, it lets you see how many dependencies your classes really have. When things start getting really annoying its a good indicator that you have too many for one class and may need to refactor.

When you are approaching release, you can always just swap in a real IOC container.


Hollywood Principle - Don't call us, we'll call you.


No idea what you're talking about mate 😕


When you use an IOC container, you just tell the container what you expect. The container decides the correct implementation to pass to your class.


Still seeking more responses because nobody has yet explained this like I'm five!


Which just proves that five-year-olds are not necessarily equipped to understand everything yet. :-)


You've completely missed the point soz!

Have I? What I am saying in a way is that some concepts cannot be explained in a few words using very simple terms because they require a complex and intricate background to start with. I think IoC/DI is such a concept.

Classic DEV Post from Jun 6 '19

What programming best practice do you disagree with?

Discussion about an unusual interview question

Evie profile image
Full stack developer and Hawaiian shirt lover from the UK. I love cheese, real ale and playing the drums :->