Menu
A metaphor that stuck with me when programming non-DI systems is "a person playing with his/her toys". A person being an object and the person's toys being anything that object creates, stores, initializes, and manipulates. The toys can dispatch events when they reach a certain state, but they know nothing about the person using them; they're just little black boxes with control switches that make up their interfaces. The person can listen for events from the toys and respond by manipulating their interfaces. The person can do whatever he/she wants with his/her toys, but he/she probably shouldn't go meddling with their innards because they might break.
The havoc that DI wreaks upon my metaphor is that it turns the toys into conscious beings that know their owner, the person using them. The toys can manipulate this person, but the person knows nothing of how they work and doesn't even care. The person just owns the toys and expects the toys to manipulate him/her to the toys' own satisfaction.
WTF?? That sounds horrible!!
What is a good mental metaphor they've been using to think of how DI systems work?
937
Dependency Injection (DI) is a programming technique that makes a class independent of its dependencies. Creating objects directly within the class is inflexible because it commits the class to particular objects and makes it impossible to change the instantiation later independently from the class.
What is dependency injection? Classes often require references to other classes. For example, a Car class might need a reference to an Engine class. These required classes are called dependencies, and in this example the Car class is dependent on having an instance of the Engine class to run.
Suggested approach: Dependency injection is the practice of creating an object and tell it what data it should work with, rather than letting that object query its environment to find that data for itself.
Dependency injection is a programming technique that makes a class independent of its dependencies. It achieves that by decoupling the usage of an object from its creation. This helps you to follow SOLID's dependency inversion and single responsibility principles.
Think a gentleman and his butler. The butler (the DI framework) provides to the gentleman any services (external dependencies) he needs upon demand (and some, like the morning coffee, upon "initialization" :-)); the gentleman (your class) just consumes the services and does not care where they come from, as long as they meet his requirements (implement certain interface).
Or if you want to make it closer to your metaphor, your class is the kid, the DI framework is the mom, and the toys are the other components. The kid doesn't care where the toys come from, as long as she can play the way she wants with them.
144
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
