【ITニュース解説】Dependency Injection in Angular: A Complete Guide with Use Cases

システムエンジニアを目指す皆さんにとって、現代のソフトウェア開発で欠かせない考え方の一つに「依存性の注入（Dependency Injection、略してDI）」がある。特にAngularのようなフレームワークでは、このDIがアプリケーション設計の土台となっており、その仕組みを理解することは非常に重要だ。DIは、あるプログラム部品（コンポーネントやサービスと呼ばれるもの）が、動くために必要な別の部品（これを「依存関係」と呼ぶ）を、自分で作らずに外部から受け取るための設計パターンだ。

例えば、ユーザーの情報を扱う「UserComponent」という部品があったとする。このUserComponentが「UserService」という、実際にユーザーデータを取得・保存する部品を必要とする場合を考えてみよう。DIを使わない場合、UserComponentの中で直接userService = new UserService();のようにUserServiceを自分で作ることになる。これは一見シンプルに見えるが、UserComponentとUserServiceが強く結びつきすぎてしまう（「密結合」と呼ぶ）。UserServiceの作り方が変わったり、別の種類のUserServiceを使いたいと思ったりした場合、UserComponentのコードも修正しなければならなくなり、柔軟性に欠ける。

一方でDIを使うと、UserComponentは「UserServiceが欲しい」と宣言するだけで、具体的なUserServiceのインスタンスは外部が用意して渡してくれる。Angularでは、これをコンストラクタ（部品が作られるときに最初に実行される部分）でconstructor(private userService: UserService)のように宣言することで実現する。この場合、UserComponentはUserServiceの作り方を知る必要がなくなり、UserServiceのインスタンスを「注入（inject）」される形になる。これにより、UserComponentとUserServiceの関係は「疎結合」となり、お互いの変更が影響しにくく、コードの再利用性やテストのしやすさが格段に向上する。

Angularには、この依存関係を管理し、適切な場所に注入するための「インジェクター」というシステムが備わっている。このインジェクターは階層構造になっており、アプリケーションの様々なレベルで依存関係を提供できるようになっている。最も広範囲に適用されるのが、アプリケーション全体で一つだけ存在する「ルートインジェクター」だ。サービスを@Injectable({ providedIn: 'root' })と設定すると、そのサービスはアプリケーション全体でただ一つのインスタンス（「シングルトン」と呼ばれる）として利用され、どの場所からでも同じデータにアクセスできる。これは、アプリケーション全体で共有すべきデータや機能を持つサービスに最適だ。

次に、特定の「モジュール」の中で依存関係を提供する方法がある。@NgModuleデコレーターのprovidersプロパティにサービスを指定すると、そのサービスはそのモジュール内でのみ共有される。例えば、ユーザー関連機能を集めた「UserModule」で提供されたUserServiceは、そのUserModule内のコンポーネントやサービスから利用できるが、他のモジュールからは直接利用できない。これにより、アプリケーションを機能ごとに分割し、それぞれの独立性を保ちやすくなる。

さらに細かく、特定の「コンポーネント」とその子コンポーネントのみで依存関係を提供することも可能だ。@Componentデコレーターのprovidersプロパティにサービスを指定すると、そのコンポーネントが生成されるたびに、サービスの新しいインスタンスが作られる。これは、それぞれのコンポーネントが独立した状態を持つ必要がある場合、例えばフォームの入力状態を管理するサービスなどに適している。このように、AngularのDIは、アプリケーションの規模や要件に応じて、柔軟にサービスのスコープ（利用範囲）を制御できる仕組みを提供している。

依存関係を提供する主な方法は、前述したように「providedIn: 'root'を使う方法」、「モジュールのprovidersに設定する方法」、「コンポーネントのprovidersに設定する方法」の三つがある。特にprovidedIn: 'root'は、そのサービスが不要な場合にアプリケーションの最終的なコードから自動的に取り除かれる（「ツリーシェイク可能」と呼ばれる）ため、アプリケーションの軽量化にも貢献し、特別な理由がない限りは推奨される方法だ。

DIの具体的な活用例を見ていこう。第一に、「コンポーネント間でのデータ共有」がある。深い階層にあるコンポーネント間でデータをやり取りする際に、共通のサービスをprovidedIn: 'root'で提供し、そこにデータを保持することで、どのコンポーネントからも同じデータにアクセスし、更新できる。これにより、コンポーネント間の複雑な親子関係を介したデータ受け渡しを避けることができ、コードがシンプルになる。

第二に、「InjectionTokenを使った設定可能なサービス」の実現だ。例えば、アプリケーションが外部APIと通信する場合、開発環境と本番環境でAPIのURLが異なることがある。このような設定値を直接コードに埋め込むのではなく、「InjectionToken」という特別な識別子を使って、API_URLなどの設定値を外部から注入できるようにする。@NgModuleのprovidersで{ provide: API_URL, useValue: 'https://api.example.com' }のように設定することで、アプリケーションの構成時にURLを指定でき、コードの変更なしに環境ごとに異なる設定を適用できるようになる。

第三に、「テスト時の依存関係のモック」だ。DIの最大の利点の一つは、テストのしやすさにある。例えば、データベースと連携するサービスをテストしたい場合、実際にデータベースに接続するとテストが複雑になり、時間がかかる。DIを使えば、テスト時にそのサービスの代わりに、ダミーの動作をする「モック」サービスを注入できる。これにより、データベースとの接続を気にすることなく、テスト対象の機能だけを独立して素早く検証することが可能になる。

第四に、「useClass、useValue、useFactoryを使った多様な実装の切り替え」だ。AngularのDIシステムは、単にインスタンスを注入するだけでなく、より高度な制御も可能にする。例えば、「useClass」を使うと、元のサービス名の代わりに別のクラスの実装を注入できる。これは、ロギング機能など、機能は同じだが実装方法を切り替えたい場合に便利だ。「useValue」は、文字列や数値のような静的な値を直接注入したい場合に使う。「useFactory」は最も強力で、特定の条件に基づいて、どのサービスを注入するかを動的に決定できる。例えば、アプリケーションが開発環境で動作しているか、本番環境で動作しているかに応じて、異なるAPIサービスを注入するといったことが可能だ。これは、アプリケーションの実行環境に合わせた柔軟な振る舞いを実現する上で非常に役立つ。

第五に、「コンポーネントレベルでの機能別サービス」だ。特定のコンポーネントが独自のライフサイクルを持つデータを管理したい場合、そのコンポーネントのprovidersにサービスを提供することで、そのコンポーネントが作られるたびに専用のサービスインスタンスが割り当てられる。これにより、他のコンポーネントに影響を与えることなく、そのコンポーネント固有の状態を安全に管理できる。

このように、AngularのDIシステムは、プログラムの各部品間の結びつきを弱め（疎結合）、個々の部品のテストを容易にし、サービスの再利用性を高める。また、InjectionTokenやuseFactoryを使うことで、アプリケーションの設定や動作を非常に柔軟に構成できる。これらの利点により、大規模なアプリケーションでも管理しやすく、将来的な拡張にも強い構造を作り上げることが可能になる。システムエンジニアとして、モジュラーでテストしやすく、保守性の高いコードを書くためには、DIの概念とそのAngularでの実装方法を習得することが不可欠だ。

サービスを提供する場所（ルート、モジュール、コンポーネント）を慎重に選ぶことは重要だが、基本的には「providedIn: 'root'」の使用を心がけるべきだ。これは、アプリケーションの軽量化と一貫性の確保に役立つ。依存性の注入をマスターすることで、皆さんはAngularアプリケーション開発の質を大きく向上させることができるだろう。