Menu
Someone on the Herding Code podcast No. 68, http://herdingcode.com/herding-code-68-new-year-shenanigans/, stated that IOC containers had no place with Python or Javascript, or words to that effect. I'm assuming this is conventional wisdom and that it applies to all dynamic languages. Why? What is it about dynamic languages that makes IOC containers unnecessary?
850
The IoC container that is also known as a DI Container is a framework for implementing automatic dependency injection very effectively. It manages the complete object creation and its lifetime, as well as it also injects the dependencies into the classes.
The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode.
Spring IoC ContainerTo achieve loose coupling and dynamic binding of the objects at runtime, objects dependencies are injected by other assembler objects. Spring IoC container is the program that injects dependencies into an object and make it ready for our use.
Python is an interpreted language with a dynamic typing. There is an opinion that dependency injection doesn't work for it as well as it does for Java. A lot of the flexibility is already built in. Also there is an opinion that a dependency injection framework is something that Python developer rarely needs.
IoC provides a mechanism to break the coupling you get when an object calls 'new' on another class. This coupling ties the calling object with the instantiated implementation of whatever interface it implements.
In static languages when you reference a class by name (to call new on it), there is no ambiguity. This is a tight coupling to a specific class.
In dynamic languages calling new X is a placeholder for "instantiate whatever class is defined as X at the point of execution". This is a looser coupling, as it's only coupled to the name X.
This subtle difference means that in a dynamic language you can usually change what X is, so the decision as to which class is instantiated is still modifiable outside of the calling class.
However, personally I find there are two advantages to IoC that I don't get by relying on the dynamic language to allow injection.
One of the side effects of passing dependencies in through constructors is that you end up with "building block" classes that are very decoupled, reusable and easy to test. They have no idea what context they are intended to be used in, so you can reuse them all over the place.
The other result is having explicit code to do the wiring. Done correctly this cleanly represents the structure of your application and it's decomposition into subsystems and life-cycles. This makes people explicitly decide which life-cycle or subsystem they want to associate their class with (when writing the wiring code), and concentrate on the behavior of the object when writing the class.
Like Jörg W Mittag said.. "Those tools are unnecessary, the design principles aren't." I believe they are unnecessary, but done right, still valuable.
138
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
