はじめに
「DI（依存性の注入）」って難しそう...と思っていませんか？
実は、DIはとてもシンプルな考え方です。
この記事では、DIを難しく感じていた人に向けて、
「DIは外部から参照をもらうだけ」
という本質をわかりやすくお伝えします。
※依存性の注入を以後「DI」と表記します。
記事の対象
-
今までサービスロケーターを使っていたけど、DIが気になっている人
-
昔DIに挑戦したが、メリットがわからずやめた人
-
これからDIを覚えたいと思っている人
依存性の注入（DI）とは？
DIの本質：「外部から参照をもらうだけ」
これだけです。
めちゃくちゃシンプルですよね。
では、なぜDIが難しく感じられるのでしょうか？
理由は主に3つあります。
DIが難しく感じる理由
1. 「DIにはコンテナが必須」と誤解している
DIは専用ライブラリ（DIコンテナ）がなくても、手動で実装できます。
まずはコンテナなしで、DIの雰囲気を掴んでみましょう！
サンプルコード
class Program
{
static void Main(string[] args)
{
ILogger logger = new LogSystem();
Hoge hoge = new Hoge(logger);
hoge.Execute();
}
}
public interface ILogger
{
void Log();
}
public class LogSystem : ILogger
{
public void Log()
{
Console.WriteLine("Hello, World!");
}
}
public class Hoge
{
private readonly ILogger _logger;
public Hoge(ILogger logger)
{
_logger = logger;
}
public void Execute()
{
_logger.Log();
}
}
このコードは、「ログを出力するだけ」のシンプルな例です。
-
MainメソッドでILoggerの実装（LogSystem）を生成し、Hogeに渡しています。 -
Hogeクラスでは、渡されたILoggerを使ってログ出力を実行しています。
ポイントは
「使う側（Hoge）が依存先（LogSystem）を直接 new していない」
ことです。
たったこれだけでDIは出来ています！
2. DIを「目的化」してしまっている
DIは目的ではありません。
疎結合でテストしやすいコードを書くための手段です。
たとえば、SOLID原則の「依存性逆転の原則（DIP）」ではこう述べています。
-
高水準モジュール（ビジネスロジック）は、低水準モジュール（詳細実装）に依存してはいけない。
-
両者は抽象（インターフェース）に依存すべきである。
DIでの依存性の逆転の実現方法としては
依存性の逆転は、何を達成したいのか(what)に対して
DIは依存性の逆転をどのように達成したいのか(how)
DIは手段なのです
DIを使えば、自然とこの形を実現できるのです。
3. 「どこにDIを使えばいいかわからない」
これもよくある難しい思うポイントです(正直、自分もよく悩みます)
そんなときは、「設計パターンや原則に沿うかどうか」 を判断基準にするとよいでしょう。
-
外部リソースを扱うクラス（例：DBアクセス、ファイル操作、ログ出力）
Repositoryパターン など -
動作を差し替えたい箇所（例：テスト時にモックを使いたい場所）
オープンクローズドの原則 や 依存性の逆転など
には、積極的にDIを使うべきです。
逆に、自明な内部処理（単純な計算など） には無理に使う必要はありません。
更にDIを何でもかんでも注入すると 網目の依存 になるので注意すべきです
DIを使うか迷ったら、こう考えてください。
-
「このクラスの動作を将来変更・テストしたいか？」
-
→ YESならDIする価値あり！
まとめ
-
DIの本質は**「外部から参照をもらうだけ」**です
-
DIコンテナが無くても手動DIで十分DIのやりたいことが出来ます！
-
DIは手段であり、疎結合でテストしやすい設計を助けるものです
参考にした記事や書籍