2025年6月21日·1 分
依存性注入がテスト性とモジュール性を向上させる方法
依存性注入（DI）がコードのテスト容易性、リファクタ性、拡張性をどう高めるかを学びます。実践パターン、サンプル、避けるべき落とし穴を解説します。
依存性注入（DI）がコードのテスト容易性、リファクタ性、拡張性をどう高めるかを学びます。実践パターン、サンプル、避けるべき落とし穴を解説します。
Dependency Injection（DI）は単純な考えです：コードが必要とするものを自分で作るのではなく、外から「与える」ようにする、ということです。
その「必要なもの」は依存物です—たとえばデータベース接続、決済サービス、クロック、ロガー、メール送信機能など。コードがそれらを自分で作ると、どのようにそれらが動くかを暗黙に固定してしまいます。
オフィスのコーヒーマシンを想像してください。水、コーヒー豆、電力が必要です。
DIは後者のアプローチに相当します："コーヒーマシン"（あなたのクラス／関数）はコーヒーを作ることに集中し、"消耗品"（依存物）はセットアップする人が提供します。
DIは特定のフレームワークを使うことを要求するものではなく、DIコンテナと同義でもありません。依存をパラメータ（またはコンストラクタ）で渡すだけの手動DIでも充分です。
またDIは“モッキング”そのものではありません。モッキングはテストでDIを利用する一手段に過ぎず、DI自体は依存関係がどこで生成されるかという設計上の選択です。
依存物が外部から提供されると、コードは本番、単体テスト、デモ、将来の機能など、異なるコンテキストで実行しやすくなります。
その柔軟性がモジュール設計もきれいにします：部品を差し替えてもシステム全体を書き換える必要がなくなります。その結果、テストは速く明瞭になり（単純な代替を差し替えられるため）、コードベースは変更しやすくなります（部品同士のもつれが減るため）。
タイトカップリングは、ある部分のコードが直接どの部分を使うべきか決めてしまうときに起きます。最も一般的な形はシンプルです：ビジネスロジックの中で new を呼ぶこと。
たとえばチェックアウト関数が内部で new StripeClient() や new SmtpEmailSender() を呼んでいるとします。最初は便利に見えますが、そのチェックアウトフローはそれらの実装、設定、生成ルール（APIキー、タイムアウト、ネットワーク挙動）に固定されてしまいます。
その結合はメソッドのシグネチャからは見えにくいため「隠れた」結合になります。関数は注文を処理するだけに見えて、実は決済ゲートウェイやメールプロバイダ、場合によってはデータベース接続にも依存していることがあります。
依存がハードコードされていると、小さな変更でも波及します：
ハードコードされた依存は単体テストで実際の作業（ネットワーク呼び出し、ファイルI/O、クロック、ランダムID、共有リソース）を行わせます。テストは隔離されておらず遅く、不安定になります（タイミングや外部サービスに依存するため）。
以下のパターンが見られたら、タイトカップリングが既にコストを生んでいる可能性があります：
newDependency Injectionは依存を明示化し交換可能にすることで、この問題に対処します—ビジネスルールを書き換えることなく。
IoCは責任の単純なシフトです：クラスは何をするかに集中し、それに必要なものをどう得るかは担うべきではないという考えです。
クラスが自身で依存を作る（new EmailService() や直接DB接続を開くなど）と、ビジネスロジックとセットアップの二つの仕事を負うことになります。これではクラスは変更しにくく、再利用もしにくく、テストもしにくくなります。
IoCではコードはインターフェースや小さな契約のような抽象に依存します。例えば CheckoutService は決済がStripeかPayPalかフェイクかを知らなくてよく、「カードを請求できる何か」があれば足ります。CheckoutService が IPaymentProcessor を受け取る形にすれば、その契約に従う任意の実装で動作します。
こうしてコアロジックは下層のツールが変わっても安定します。
IoCの実践は依存の生成をクラスの外に出して渡すことです（多くの場合コンストラクタを通じて）。これがDependency Injectionの役目です。
代わりに：
こうなります：
結果として振る舞いの切り替えは構成の問題になり、書き換えではなく設定の変更で済むようになります。
クラスが依存を作らないなら、誰かがそれを行う必要があります。その「誰か」がcomposition rootです：アプリが組み立てられる場所—通常は起動コードです。
composition rootでは「本番では RealPaymentProcessor を使い、テストでは FakePaymentProcessor を使う」と決めます。配線を一か所にまとめることで驚きが減り、コードベースの残りは行動に集中できます。
IoCは単体テストを簡単にします。小さく速いテストダブルを提供できるからです。本番のネットワークやDBに触れないため、リファクタも安全です：責務が分離されていれば、実装を変えてもそれを使うクラスを変更する必要はほとんどありません（抽象が変わらない限り）。
DIは一つの手法ではなく、クラスに依存物（ロガー、DBクライアント、決済ゲートウェイなど）を「与える」方法の集合です。スタイルの選択は明瞭さ、テスト性、誤用しやすさに影響します。
コンストラクタ注入は、オブジェクトを構築する際に依存が必須になります。大きな利点は依存を忘れられないことです。
次の場合に最適です：
コンストラクタ注入は最も明瞭なコードと単純な単体テストを生みます。テストでは作成時にフェイク／モックを渡せます。
依存が単一の操作でしか必要ない場合（例：一時的なフォーマッタ、特別な戦略、リクエストスコープの値）は、メソッドの引数として渡します。これによりオブジェクトを小さく保てます。
生成時に依存を渡せない場合に便利ですが、要求が隠れることがあり、実行時の驚きやテストの脆弱性につながります。ドキュメント、検証、fail-fast チェックを加えてください。
単体テストは「速く」「再現可能で」「一つの振る舞いに集中している」ほど価値があります。テストが実際のDBやネットワーク、ファイルシステム、クロックに依存すると遅くなり、不安定になります。失敗しても原因が分かりにくくなります。
DIはこれらの依存（DBアクセス、HTTPクライアント、時間提供など）を外部から受け取るようにすることで、テスト時に軽量の代替を差し替えられるようにします。
実DBやAPI呼び出しはセットアップ時間と遅延を生みます。DIを使えばインメモリリポジトリやフェイククライアントを注入でき、即座に応答を返します。結果：
DIがないとコードは自分で依存を生成し、テストはスタック全体を実行せざるを得ません。DIを使うと：
グローバルスイッチやハック不要で、単に別の実装を渡します。
DIによりセットアップが明示的になります。設定ファイルや接続文字列、テスト専用環境変数を探す代わりに、テストを読めば何が実際で何が代替かがすぐ分かります。
典型的なDIフレンドリなテストは：
この直接性が雑音を減らし、失敗原因の特定を容易にします。
テストシームは、振る舞いを入れ替えられるようにした設計上のポイントです。本番では本物を、テストでは安全で速い代替を差し込みます。DIは余計なハックなしにシームを作る最も単純な手段の一つです。
テストで扱いにくい次のような部分の周りにシームを作ると便利です：
ビジネスロジックがこれらを直接呼ぶと、テストが脆弱になり実行が難しくなります。
シームはしばしばインターフェースや「このオブジェクトは now() を持つべき」などの小さな契約の形を取ります。依存すべきはどこから来るかではなく何が必要かです。
例えば、注文サービスの中でシステムクロックを直接呼ぶ代わりに Clock に依存すると：
SystemClock.now()FakeClock.now() は固定時刻を返すファイル読み込み（FileStore）、メール送信（Mailer）、カード請求（PaymentGateway）などにも同様のパターンが使えます。コアロジックは変わらず、差し込む実装だけが変わります。
振る舞いを意図的に差し替えられると：
適切に配置されたシームはあちこちでモックする必要を減らし、いくつかのきれいな差し替えポイントによって単体テストを速く集中したものにします。
モジュール性とは、ソフトウェアが責務が明確で相互作用が定義された独立した部品で構成されることです。DIはそれらの境界を明示的にすることでモジュール性を支援します。
モジュールが自分で何でも作るのではなく、必要なものを外から受け取るようにすると、あるモジュールが別のモジュールの内部をどれだけ知っているかが減ります。
コードが内部で依存を生成すると（例：サービス内でDBクライアントを new する）、呼び出し元と依存が強く結びつきます。DIはインターフェース（または単純な契約）に依存することを奨励します。
結果としてモジュールは通常以下だけを知っていればよくなります：
PaymentGateway.charge()）そのためモジュール同士が一緒に頻繁に変わる必要がなくなります。
モジュール化されたコードベースでは、コンポーネントを交換してもそれを使う側を大幅に書き換える必要がないべきです。DIはこれを実現します：
どの場合も呼び出し側は同じ契約を使い、配線の変更はcomposition rootの一か所で済みます。
依存境界が明確だとチームは並行して作業できます。一方のチームがインターフェースの裏で新しい実装を構築している間に、別のチームはそのインターフェースを使った機能開発を進められます。
DIは段階的なリファクタも助けます：モジュールを切り出して注入し、段階的に置き換えることができます。
コードでDIを見ると理解が早まります。ここでは通知機能の小さな“前と後”を示します。
クラスが内部で new を呼ぶと、どの実装を使いどう組み立てるかを決めてしまいます。
class EmailService {
send(to, message) {
// talks to real SMTP provider
}
}
class WelcomeNotifier {
notify(user) {
const email = new EmailService();
email.send(user.email, "Welcome!");
}
}
テストの問題点: 単体テストで実際のメール送信が走る危険があり（あるいはグローバルなスタブが必要になる）、テストが難しくなります。
test("sends welcome email", () => {
const notifier = new WelcomeNotifier();
notifier.notify({ email: "[email protected]" });
// Hard to assert without patching EmailService globally
});
WelcomeNotifier は必要な振る舞いを満たす任意のオブジェクトを受け取れるようになります。
class WelcomeNotifier {
constructor(emailService) {
this.emailService = emailService;
}
notify(user) {
this.emailService.send(user.email, "Welcome!");
}
}
テストは小さく、速く、明示的になります。
test("sends welcome email", () => {
const fakeEmail = { send: vi.fn() };
const notifier = new WelcomeNotifier(fakeEmail);
notifier.notify({ email: "[email protected]" });
expect(fakeEmail.send).toHaveBeenCalledWith("[email protected]", "Welcome!");
});
後でSMSを追加したくなったら、WelcomeNotifier を触る必要はありません。別の実装を渡すだけです：
const smsService = { send: (to, msg) => {/* SMS provider */} };
const notifier = new WelcomeNotifier(smsService);
これが実務上の効果です：テストが構築の詳細と戦わなくなり、新しい振る舞いは依存の差し替えによって追加されます。既存コードの書き換えは不要です。
DIは単に「必要なものを渡す」だけの手作業から、配線を自動化するDIコンテナまで幅があります。どの程度の自動化が適切かを見極めることが肝心です。
手動DIではオブジェクトを自分で作り、コンストラクタや引数で依存を渡します。利点：
手動配線は良い設計習慣を促します。もしオブジェクトが7つの依存を必要としているなら、その痛みがすぐ分かり、責務分割の合図になります。
コンポーネント数が増えると手動配線が冗長になることがあります。DIコンテナは：
コンテナは境界とライフサイクルが明確なアプリ（ウェブアプリや長時間実行サービス）に向きます。
コンテナは配線を消してしまうため、密結合な設計が「すっきり」して見える危険があります。潜在的な問題は残ります：
コンテナを入れてコードが読みづらくなったら行き過ぎです。
初めは手動DIで明快さを保ち、配線が重複して辛くなったらコンテナを導入するのが実践的です。
実用的なルール：コア／ビジネスコードは手動DIで書き、アプリ境界（composition root）で必要ならコンテナを使う。こうすれば設計の明快さを保ちつつ、成長に合わせてボイラープレートを減らせます。
DIは正しく使えばコードをテストしやすく変更しやすくしますが、規律を欠くと問題になります。主な失敗例と対処法：
クラスが長い依存リストを要求するなら、やりすぎの兆候です。これはDIの失敗ではなく、DIが設計の臭いを露呈した結果です。
対策：クラスの仕事内容を一文で説明できないなら分割を検討するか、関連する操作を慎重にまとめて小さな抽象にする（ただし“ゴッドサービス”を作らないよう注意）。
ビジネスコード内で container.get(Foo) のように呼ぶと依存が見えなくなります。便利に見えますが、テストではグローバルな設定を用意する必要があり、依存関係が不明瞭になります。コンストラクタ注入のように明示的に渡す方法を優先してください。
DIコンテナは以下で実行時に失敗することがあります：
これらは配線が実行されるまで分からないため厄介です。
コンストラクタを小さく保つ。依存リストが増えるならリファクタの合図と捉えてください。
配線の統合テストを追加する。composition root をビルドする簡易テストがあれば登録漏れや循環は早期に検出できます。
最後に、オブジェクト生成は一か所（起動／composition root）にまとめ、ビジネスロジック内でコンテナ呼び出しを避けることで、DIの主目的である「何が何に依存しているかの明確さ」を保てます。
DIは小さな、低リスクのリファクタの連続として導入するのが最も容易です。まずはテストが遅い・脆弱な箇所、変更が波及しやすい箇所から始めてください。
次のような依存はDIの効果が高いです：
プロセス外に出なければ動かない関数はDI化の候補です。
new しているか直接呼んでいる外部依存を選ぶ各変更はレビューしやすく、途中で止めてもシステムが壊れることはありません。
DIは依存を大量に注入してしまうと「何にでも依存する」コードになりがちです。
実践ルール：詳細ではなく能力を注入する。例：Clock を注入し、"SystemTime + TimeZoneResolver + NtpClient" を注入しない。クラスが5つの無関係なサービスを必要としているなら責務分割を検討してください。
また「念のため」複数レイヤーへ依存を渡し回すのは避け、依存は使う箇所にだけ注入し、配線は一か所にまとめてください。
コードジェネレータや素早く機能を作るワークフローを使っている場合、DIは構造を保つのに役立ちます。たとえば、Reactフロントエンド、Goサービス、PostgreSQLバックエンドをチャットベースの仕様から生成するツールを使う際、明確なcomposition rootとDIフレンドリなインターフェースを保つことで、生成コードをテストしやすく、統合（メール、決済、ストレージ）を差し替えやすくできます。
基本ルールは変わりません：オブジェクト生成と環境特有の配線は境界に置き、ビジネスコードは振る舞いに集中させる。
具体的な改善を示せるはずです：
次のステップとしては、composition root を文書化しておきましょう：1つのファイル（または一か所）で依存を配線し、残りのコードは振る舞いに集中させるのが理想です。
Dependency Injection（DI）は、コードが必要とするもの（データベース、ロガー、クロック、決済クライアントなど）を内部で作るのではなく、外部から「渡す」ことを意味します。
実務的には、依存物をコンストラクタや関数の引数として渡し、明示的かつ差し替え可能にすることが多いです。
制御の反転（IoC）は広い概念で、「クラスは何をするかに集中し、協力者をどう得るかは外部に任せる」という考えです。
DIはその実現手段の一つで、依存関係の生成を外に出して渡すことでIoCを達成します。
ビジネスロジック内で new を使って依存物を生成すると、その依存物を置き換えるのが難しくなります。
結果として：
DIによりテスト用のダブルを注入できるので、テストは「速く」「決定的」になります。実際に行われる置き換えの例：
DIコンテナは任意です。小〜中規模のアプリやオブジェクトグラフが手作業で組めるなら、まずは手動DI（依存を明示的に渡す）から始めましょう。コンテナを検討するのは、配線が繰り返し多くなったりライフサイクル管理（シングルトン/リクエスト毎など）が必要になったときです。
コンストラクタ注入：オブジェクトが動作するために常に必要で、複数メソッドで共有される依存に使います。
メソッド／パラメータ注入：一回限りの処理やリクエストスコープの値に向きます。
セッター／プロパティ注入：どうしても生成時に提供できない場合に使いますが、欠如による実行時エラーを防ぐために検証を入れるべきです。
Composition Root（合成ルート）はアプリを組み立てる場所です：実装を生成して、それらを必要なサービスに渡す場所を指します。
一般的にはアプリの起動近く（エントリポイント）に置き、残りのコードは振る舞いに集中させます。
テストシームは振る舞いを差し替えられる意図的な“開口”です。
テストで差し替えたい箇所（時間、ファイルI/O、外部サービスなど）にインターフェースや契約を用意し、本番では実装、テストではフェイク／スタブを注入します。
よくある誤り：
container.get() のようにビジネスコード内で取得すると依存が見えなくなり、テストが難しくなります。明示的な注入を優先しましょう。安全に導入する手順：
この手順は繰り返しでき、どのステップでも止められるため大掛かりなリライトは不要です。