The problem
What dependency injection frameworks like Dagger essentially brings to the table, as opposed to plain/ pure/ vanilla dependency injection is a set of conventions.
(Dagger in particular is performant, offers a lot of useful features and quite easy to understand under the hood with its generated code)
It’s hard to fault Dagger’s conventions except for one: naming. It has been a major contributor to the steep learning curve and the struggle to transfer knowledge to new joiners, at least in my 4 years of experience working with Dagger.
Let us fix it 😄
1. AppScope instead of Singleton
Singleton is confusing because it’s an existing concept in object oriented programming and it’s different from Dagger’s Singleton scope.
2. Injector instead of Component
Component has a very broad meaning. Imagine trying to use your own “Component” in your design library or backend-driven UI framework alongside Dagger’s Component 😅
Dagger Hilt seems to agree with me on this one 😎
3. Contribute and RequestDependency instead of Inject
Depending on the situation, @Inject could mean either one of the following:
- Automatic service discovery — when used at constructor site of a service e.g. UseCase, Repository it means: “let this service join the dependency graph”
class SomeService @Inject constructor(dependency: SomeObject) {}@Contribue would be more descriptive and appropriate in my opinion:
2. Class members injection — here it means “pull the specified object from the dependency graph and injects it into this object (often Activity, Fragment, Service) which may or may not be a part of the dependency graph
class SomeActivity: AppCompatActivity {@Inject lateinit var someService: SomeService
}
@RequestDependency would be much better:
Notes
@Inject is not a new annotation introduced by Dagger but rather part of javax annotation.
If you have experience working with javax annotations (I don’t ) and see som great benefits of @Inject I would love to hear.
Half of the documentation here or here doesn’t immediately make sense to me (The first half about injectable constructor seems easy enough to understand)
4. DependencyHolder instead of Module
Module is another generic word used by Dagger. Admittedly, Dagger’s Modules are lot more straightforward compared to Dagger’s “Component” though
Other naming conventions
Limitations
Kotlin typealias is not accessible from Java so this method is only usable in Kotlin only codebase.
What about Hilt?
Dagger Hilt has a much more sensible naming convention in my opinion. Although it still use Singleton scope instead of AppScope or Application, it does give you the option to rename the scope to what you want using AliasOf
This article does not Hilt target users. Instead, this article is for those who cannot afford to migrate legacy app to Hilt soon and those who are not a fan of Hilt (since it’s very opinionated, has some overhead and includes a lot of magic under the hood)
Full source code of a working app is here
