What is Dependency Injection?

dependency injection is a common term in object-oriented programming and while the term can sound complex the underlying idea is pretty simple instead of classes creating the objects that they depend on they are instead provided to the class at instantiation time usually via the Constructor and while this pattern is pretty simple it tends to be associated with much more complex dependency injection libraries like juice or dagger and Frameworks like angular swing or net and as a result the term can sometimes be divisive among engineers some love dependency injection While others want to get as far away from it as possible let's dive deeper what's the point of dependency injection at all where do these libraries fit in and why can the term sometimes be divisive dependency injection comes from a design principle called inversion of control this is a pattern where in order to make your code more reusable you have it accept custom input that it can defer to to perform some steps for example let's say that we're working on some code to check out a customer on an e-commerce site at some point this code is going to want to bill the customer's credit card in traditional procedural programming control flows from top to bottom so if we have a checkout function it's going to run all those statements including all the billing logic this tightly couples the billing logic with the checkout logic every time you run that checkout code you're running the same billing code with inversion of control we instead have our checkout code except some billing logic as input say in the form of a function or a class the checkout code can then call into this supplied logic when it comes time to perform the billing step this is where the term inversion of control comes from instead of following the traditional top-down control flow we have our code calling back up into the caller supplied code this pattern has several distinct advantages first there is nice separation of concerns the billing logic is now clearly separated from the checkout logic second there is loose coupling between the two the way the billing logic interacts with the the checkout logic is very clearly defined and limited through certain paths third your code is now a little bit more reusable for example if you wanted to change the billing logic to something else you can do that by providing a new input to your checkout code you don't have to change the checkout code finally it makes the code a lot easier to test you could provide a fake billing function while testing your checkout code the inversion of control pattern is very generic and can apply to functional programming and object-oriented programming you don't need a library or framework to do it in fact you've probably already used this pattern at some point without realizing it because it comes up so often with callbacks and different libraries and Frameworks in object-oriented programming one of the more popular ways to apply inversion control is dependency injection with dependency injection the logic that your class will call into or its dependencies are provided at class instantiation time usually in the form of Constructor arguments just like in our billing example this decouples your class from that sub logic and helps make the code be a little bit more Modular One of the downsides of this pattern however is that you end up with lots of glue code somewhere classes can depend on classes can depend on classes and this can create a tree of dependencies that needs to be resolved and instantiating all these classes in the right order can result in a lot of boilerplate code engineers and being the lazy people that we are decided to spend a tremendous amount of time creating dependency injection libraries to get rid of the spoilerplate these Frameworks take on the responsibility of gluing your code and their dependencies together they resolved that big web dependencies and are responsible for instantiating your class and providing all those constructive arguments that you requested they often pull this off by having you annotate your classes in some way you'll often see the term inject thrown around and this is usually used to signal that this is the class that you want the library or framework to manage these libraries come with a host of features and you're going to see a lot of terms being thrown around like injection tokens or multi-bindings or request scope bindings injectors assisted injection but all these features go back to the Frameworks original intent they're trying to support inversion of control so your code can be more modular and while they're at it they're there to remove that boilerplate the use of dependency injection libraries is debated among Engineers people who might otherwise like the principle of inversion of control and dependency injection in general might become unhappy and there are valid reasons for this while these Frameworks do get rid of glue code they do have some trade-offs first they can make your code harder to understand because they obfuscate how things are being instantiated because the framework's taking care of all of that similarly it can make things harder to debug because you have to look at stack traces and run the debugger through so much of the framework code when errors occur there's also criticism that it doesn't really get rid of all the glue code it just transforms it into configuration glue code which might be harder to understand than the original code was in the beginning and depending on the library it may actually transform what would normally be a compile time error to a runtime error making it easier to introduce bugs into production again these are all very valid concerns and as an engineer looking at using one of these dependency injection libraries you're making a trade-off between these concerns and the benefits that they provide both in reducing boilerplate as well as all the features that they offer I'm curious what people's thoughts are do you use inversion of control and dependency injection of with or without these Frameworks have you had any good or bad experiences with them feel free to comment below

Channel: Scott Bailey

Views: 113,667

Keywords:

Id: tYZd8hserms

Length: 6min 48sec (408 seconds)

Published: Mon Jan 30 2023