Dependency Injection in the Coffeeshop

By | November 7, 2016

Dependency Injection In the Coffee Shop

Inject what… in the Coffee Shop?

I believe if one would like to define an interface whose methods many people implement, it literally has to do with eating. Developers, in particular, are not an exception. The joy of coding in the coffee shop while sipping your double espresso is well known to many of us.

For those who have experienced it, getting a grasp of dependency injection in software development opens a new world to the developer. This is to the extent that once got it you are not going to code without it. Now you might ask what this has to do with the coffee shop? You will find that only after you see the dependency injection everywhere, even in your most joyful moments of having breakfast in the coffee shop… .


What do you order?

“Would you bring me breakfast with omelet as the main course and espresso for drink?” This is a sample order for breakfast in the coffee shop. To order, one needs to do the following:

The three interfaces used in the CoffeeShop class are Drink, MainCourse and Breakfast, whose implementations are in Espresso, Omelet and YourBreakfast classes per your particular breakfast order.

Now you are all set and waiting for your order to come, but this is the start of the story for the other side… .

First let’s assume the dependency injection is not used. The following picture illustrates the whole story behind the scenes then:

without DI in the coffeeshop-beforechange

Alternatively, one may also design the above using Dependency Injection (DI). As a metaphor, suppose you are a regular of the coffee shop. Being regular, you may prefer to have the same breakfast every morning and not being asked for order each time. In other words, you don’t want to care about the details of your breakfast order everyday. You are only required to provide the dependency graph of your breakfast, being dependent on a drink as well as a main course, and instantiate them all by providing concrete examples for each, e.g. Espresso and Omelet, elsewhere in some class known as DI Container. This is what the Dependency Inversion Principle (DIP) implies, as illustrated below:

DI in the coffeeshop-part1-beforechange

 

DI in the coffeeshop-part2-beforechange

You would then only have to call the serve method of breakfast in case you want breakfast.


Does it make any difference which design to choose?

To answer this question, it would be a good idea to investigate the flexibility of the above designs to possible change in breakfast order. For example, you might want to change your drink to orange juice and main course to baked beans. Let’s see how the code now changes to reflect your current request.

The first case, i.e. without dependency injection, changes like this:

without DI in the coffeeshop-afterchange-highlighted

The red parts denote the parts of the diagram to be replaced with the green ones to suit the updated order.

In the second design, i.e. with dependency injection, however, there would be no change in the first part of the diagram. The second part, involving the DI container, changes like this:

DI in the coffeeshop-part2-afterchange-highlighted

The prominent advantage of the latter design using DI over the first one is that it leaves no trace on the composition root class of, where you invoke the breakfast.serve() method. It is clear this is not true for the first case due to the instantiation being implementation in the same place as it is used. See the highlighted lines in the CoffeeShop class.
Overall, even though extensibility is the main merit of using DI as well as most design and architectural patterns, there are indeed other benefits as well. These include memory tweak by using Singleton objects or scoping their creation and convenience in writing unit tests by mocking the objects whose creation is managed by the DI container.

There are other topics on dependency injection, such as Poor Man’s DI. I will try to explain them in subsequent posts if this one finds you well. So please leave your feedback, I would really appreciate it.

Please help by spreading the word:

11 thoughts on “Dependency Injection in the Coffeeshop

  1. Venkat

    This was very useful and easy to understand. Please go ahead and post Poor Man’s DI

    Reply
  2. Russel Naylor

    No diagrams appear. Since that is where 80% of the information is for this post, it would be nice to have them. Please, please, please. 🙂

    Reply
  3. K

    I feel this would be a great example if one could just see the code samples. Unfortunately you have them on a separate Amazon instance that is currently not working. Not sure why you don’t have the images hosted on the same server as this page. As a result it is impossible to get anything from this page.

    Reply
  4. Solo Yakubu

    It’s a great job. Sir, can I get the code implementation? i would like to use as a case for my Msc disssertation. Thank You.

    Reply
    1. Ali Post author

      Thank you.
      What do you mean by the code implementation? I’ve already provided sample Java code pertaining to the example.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *