Why use Dagger?

- [Instructor] Now that understand that Dagger is an extension to the Kotlin compiler, and a dependency injection framework, and we're also comfortable with a dependency injection pattern and how it can improve modularization and make it easier to test your code, we can look at exactly how Dagger does dependency injection. In the last video we used code like this to demonstrate dependency injection. The network connection on which the network client depends is injected in it's constructor. So let's imagine what a factory that provided a network client would look like. It would probably look something like this. But now we need a way to create the network connection on which the network client depends. We have the factory but we don't have an implementation for the factory yet. We just need the new factory. Here's the new factory. But wait, the network implementation depends on an endpoint. We're going to need yet one more factory. Here's the factory that's supplies the endpoint. An instance of the network client factory can now get a fully functional network client. Let's take this one step further. Let's suppose that the main presenter from the last video needs a network client. Well we can do that with DI2. Here's a factory, it depends on the network client factory. We use the network client factory to get an instance of the network client and pass it to the newly created presenter. Now the main activity can get the main presenter on which it depends very easily. Let's look at the activity. Notice that until Android died, we could not use constructor injection to supply the presenter to the activity, there was no way to create a factory for an activity object. Instead in this code, the activity creates an instance of the factory and uses that to create the presenter. These factories are almost exactly the code that Dagger auto generates for you. So if that's all there is to it, why use Dagger at all? Well to begin with, that code was pretty boring to write, it would be even worse if the dependencies were more complex. Also arguably, all these factories make it more difficult to understand the code. They are a pretty clumsy way of saying simply this object depends on that object. It would be better if we could do that declaratively. So Dagger's goal is to make dependency injection easier and more understandable. Well that's great, but is there a downside to using Dagger? Yes there is. Dagger is really just not all smooth sailing. There are some definite downsides. First of all the documentation for Dagger is pretty horrible. Second of all, Dagger can do some very complex things with very little code, it can be pretty hard for the next guy to read. Also Dagger tries to infer your intention from just a few annotations. When it misunderstands you, it can be very difficult to figure out why. Also Dagger is lazy, it only generates code when it has to, you can have incorrect annotations that only explode when they are actually used. If this happens to some other developer, she's going to be upset. Also Dagger generates code, when there are errors in the generated code, it can be difficult to figure out what to do. In this session we explored how Dagger actually implements dependency injection and some of the pros and cons to using it. In the next session, we'll see how to set up an Android project to use Dagger.