依存性注入（DI）とHilt
本連載は、Android Jetpackを紹介しています。今回は、Hiltによる依存性注入（DI）を紹介します。
なお、今回のサンプルデータは、GitHubから参照できます。
依存とは
今回のテーマは、依存性注入です。英語では、Dependency Injection、略して、DIと言います。
まず、このDIとは何かを理解しておく必要があります。ただし、DI自体は、Android独自の仕組みではなく、2000年代前半に提唱された考え方であり、JavaによるWebアプリケーション開発でよく利用されてきています。
その後は、PHPなどの他の言語でも採用されています。このDIの考え方をAndroidで説明するにあたって、Androidアプリ開発でよくあるパターンである、図1のアーキテクチャを題材にしたいと思います。
アクティビティ／フラグメントをエントリポイントとして、ViewModel＋リポジトリを利用し、データベースにRoomを利用するものです。Roomでは、当然、RoomDatabaseを継承したAppDatabase+DAOインターフェース+エンティティを利用します。本連載でのこのパターンは、第3回で解説しています。
ここでの問題は、上流のクラスが下流のクラスに依存することです。例えば、図1の真ん中の2個を取り上げてみます。ViewModelは、内部でリポジトリを利用しています。そして、そのリポジトリを利用するために、ViewModelクラス内で、リポジトリクラスのインスタンス生成（new）を直接行っています（図2）。
直接、間接を問わず、あるクラスが別のクラスのインスタンスの生成に関与し、そのインスタンスを利用していることを「依存する」と言います。
この考えで図1を見ると、リポジトリはRoomの各クラスインスタンスに依存していることになります。ということは、ViewModelは、リポジトリだけでなく、リポジトリが利用しているRoomの各インスタンスに依存していることになります。さらに、アクティビティやフラグメントまで考えると、より複雑な依存関係となってしまっているのがわかります。
この依存関係が複雑である問題は、テストのしやすさに関わってきます。テストは、可能な限り各クラスのメソッド単位、つまり単体テストで行う方がバグの修正が容易です。
ところが、あるクラスが他のクラスに依存している場合、バグが発生したときに、そのクラスの問題なのか、依存先の問題なのか判断がつきにくくなります。単体テストを行う際は、依存関係がない状態の方が望ましいです。
