Inversion of controls using dependency injection

Photo by Matthew Fournier on Unsplash

When my colleagues suggested I write a blog on inversion of controls (IoC) using dependency injection (DI), I must confess that it was a mild struggle to succinctly collate my thoughts! However, help came through when I discovered an excellent example on a tech website…

Imagine I’m running an online retail business which sells different kinds of cabinets to a wide range of customers. Whenever a customer makes a purchase, the order is sent to a cabinet maker, who will refer to a manual and pick the necessary materials (woodwork, screws, bolts etc.) from the store. These are then delivered to the customer’s house, ready for build.

Now, let’s tickle your fancy further! Word of mouth spreads like wildfire and my business is roaring with customers. I’m manufacturing lots of furniture and piling up a whole lot of stock. I’m employing more cabinet makers and subsequently investing lots of money in manuals for the new hires. Both the flow and routine remain smooth.

Unfortunately, my screw supplier goes into administration, so I find another one to avoid any disruption to my workflow. However, this new supplier provides screws that are a bit different from the others. Integrating this new type of screw in my manual, as well as training all the cabinet makers to adopt this change, will be both time consuming and expensive.

I instead opt for a better alternative. I appoint a new person and train him with the change. I also give him the sole responsibility of distributing the appropriate tools and materials to the cabinet makers (rather than them collecting from the store) through the Fulfilment desk. It’s his duty to ensure the cabinet makers have everything they need to take to the customer’s house.

The system flow is smooth, cost effective and time efficient.

So, what does this have to do with IoC?
You may wonder how this story is relevant to my topic. Here’s the translation…

Let’s jump into the developer’s world, using code to explain this concept.

Part#1

This is fine if the CabinetMaker is only making the KitchenCabinet. What would happen if he wants to make the wall or bedroom cabinet, for example? Constructor injection will continue to grow. Let’s have an interface to handle this — we can be a bit more generic after the implementation of interface.

Part#2

Here, cabinetModel can be the kitchen cabinet, wall cabinet, bedroom cabinet etc. If we ask the CabinetMaker to build the wall cabinet, this injection will provide all the dependent materials needed to build.

This can be achieved by IoC. Here, I have used a unity container to implement IoC, but you can use any — all will do the same.

Part#3

Here, IoC (the new employee) is the place where you register all classes of your application. The fulfilmentDesk manages the cabinet, what screws it needs and its dependencies, before providing it to the CabinetMaker. Now, the only responsibility of the CabinetMaker is to build cabinet with these details

Benefits of DI:

1. Code can be easily tested with different mock implementation
   In ‘Part#1’, CabinetMaker is solely responsible for creating the KitchenCabinet. For testing, the creation of object should be done outside the code. For example, we could pass a fake KitchenCabinet in ‘Part#2’ to test the CabinetBuilder
2. Reducing responsibility
   In ‘Part#2’, the CabinetMaker is not responsible for the creation of the KitchenCabinet. It does not care how the KitchenCabinet is provided or who provides it. Its only responsibility is to MakeCabinet, and the fewer responsibilities a piece of code has, the less error-prone it becomes
3. Codes are loosely coupled. We do not need to change unrelated code
4. Improved code, making it clean and more readable.
   If you use dependency injection, you just need to initialise the KitchenCabinet once. You can then pass that object on to whatever part of code that requires it. This makes our code more reusable.

Therefore, it goes without saying that IoC enhances productivity. It also reduces the likeliness of errors arising in a workflow system that involves several processes to manage any given task.