Hiltによる依存性注入（DI）の概要と基礎

一歩進んだAndroidアプリ開発ができる「Android Jetpack」入門 第17回

　本連載は、「Android Studio2で始めるアプリ開発入門」連載、および『Androidアプリ開発の教科書』の続編にあたる内容として、Jetpackを取り上げていきます。前回は、ナビゲーションを型安全に利用する方法とKotlin DSLによるナビゲーションの定義方法を紹介しました。今回は、Hiltによる依存性注入（DI）を紹介します。

依存性注入（DI）とHilt

　本連載は、Android Jetpackを紹介しています。今回は、Hiltによる依存性注入（DI）を紹介します。

　なお、今回のサンプルデータは、GitHubから参照できます。

依存とは

　今回のテーマは、依存性注入です。英語では、Dependency Injection、略して、DIと言います。

　まず、このDIとは何かを理解しておく必要があります。ただし、DI自体は、Android独自の仕組みではなく、2000年代前半に提唱された考え方であり、JavaによるWebアプリケーション開発でよく利用されてきています。

　その後は、PHPなどの他の言語でも採用されています。このDIの考え方をAndroidで説明するにあたって、Androidアプリ開発でよくあるパターンである、図1のアーキテクチャを題材にしたいと思います。

図1：Androidアプリ開発でよくあるアーキテクチャ

　アクティビティ／フラグメントをエントリポイントとして、ViewModel＋リポジトリを利用し、データベースにRoomを利用するものです。Roomでは、当然、RoomDatabaseを継承したAppDatabase+DAOインターフェース+エンティティを利用します。本連載でのこのパターンは、第3回で解説しています。

　ここでの問題は、上流のクラスが下流のクラスに依存することです。例えば、図1の真ん中の2個を取り上げてみます。ViewModelは、内部でリポジトリを利用しています。そして、そのリポジトリを利用するために、ViewModelクラス内で、リポジトリクラスのインスタンス生成（new）を直接行っています（図2）。

図2：ViewModelではリポジトリクラスを直接newしている

　直接、間接を問わず、あるクラスが別のクラスのインスタンスの生成に関与し、そのインスタンスを利用していることを「依存する」と言います。

　この考えで図1を見ると、リポジトリはRoomの各クラスインスタンスに依存していることになります。ということは、ViewModelは、リポジトリだけでなく、リポジトリが利用しているRoomの各インスタンスに依存していることになります。さらに、アクティビティやフラグメントまで考えると、より複雑な依存関係となってしまっているのがわかります。

　この依存関係が複雑である問題は、テストのしやすさに関わってきます。テストは、可能な限り各クラスのメソッド単位、つまり単体テストで行う方がバグの修正が容易です。

　ところが、あるクラスが他のクラスに依存している場合、バグが発生したときに、そのクラスの問題なのか、依存先の問題なのか判断がつきにくくなります。単体テストを行う際は、依存関係がない状態の方が望ましいです。