Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
20
Help us understand the problem. What is going on with this article?
@saeki4n

Dependency Injection: 依存性の注入 のお役立ち例

More than 1 year has passed since last update.

はじめに

 「Dependency Injection: 依存性の注入」 って、とっても分かりづらくないですか?
 色んなところに解説記事があって、Qiitaでも検索すると沢山見つかりますが筆者は文章を読んだだけでは全然分かりませんでした。
 「直接呼び出すのではなく、インターフェースを介して実装する?」「制御の反転(inversion of control)? 中から外ではなく外から中?」「サンプルを真似てみたけど複雑な実装している。これ何が嬉しいの?」そんな疑問ばかりでした。言葉は知っているけど使えないってやつです。

 ようやく理解できたのは、実際に「あれ?困ったぞ」となって「ここでDIを使うと便利なのか!」と実感してからでした。
 「ここで便利なんだ!」や「こういう時に使うといいんだ!」という使い所が分かると応用が効き、これが本当に理解することなんだなと思いましたので、それを書いてみたいと思います。
 あくまで「使い所の例」ですので、そもそもの概念的なところは他の記事を参照されると良いかと思います。
例:

 なお、サンプルはC#で書いていますが、何か一つでもオブジェクト指向言語を学ばれている方でしたら問題なく理解できると思います。
 

DIを使わない例

天気に応じてメッセージを変える機能

 それでは明日の天気に応じて出力するメッセージを変えるという機能を例にしていきたいと思います。素直に書くとこんな感じでしょうか。天気の情報の取得はWeatherService()が担当しています。

    /// <summary>
    /// メッセージを担当するクラス
    /// </summary>
    public class Messenger
    {
        /// <summary>
        /// メッセージを取得する
        /// </summary>
        /// <returns></returns>
        public string GetMessage()
        {
            var service = new WeatherService();
            var tomorrowWeather = service.GetTomorrowWeather();
            switch (tomorrowWeather)
            {
                case "晴れ":
                    return "明日は良い天気です。頑張りましょう";
                case "雨":
                    return "明日は雨みたいです。傘を忘れないように!";
                case "曇り":
                    return "明日は曇りのようです。気をつけて!";
                default:
                    throw new Exception("想定外エラー");
            }
        }
    }

テストが出来ない

 これのテストコードを書くとすると次のようになりますが、このままですとテストをするタイミングによって結果が変わってしまいます。明日が晴れの時にはテストは成功しますが、雨の時にはテストは失敗します。実行するタイミングで結果が変わるなんて嫌ですね。

    [TestClass]
    public class MessengerTest
    {
        [TestMethod]
        public void GetMessage_晴れの時のテスト()
        {
            // Arrange
            var messenger = new Messenger();

            // Act
            var msg = messenger.GetMessage();

            // Assert
            Assert.AreEqual("明日は良い天気です。頑張りましょう", msg);
        }
    }

 また、もし仮にタイミングを合わせられたとしても、GetTomorrowWeather()が出来ていないとテストができません。一人で作っているなら「GetTomorrowWeather()の作成から優先しよう」で解決できますが、大抵の開発プロジェクトは複数人で作っているわけで、「GetTomorrowWeather()の担当者が早くしてくれないと、Messenger()担当者の仕事が進まないんだけど…」という状態になるのは宜しくありません。

現時点でのGetTomorrowWeather()の状態
    public class WeatherService
    {
        public string GetTomorrowWeather()
        {
            return null;
        }
    }

テストが出来ないのは依存しているから

 何故テストできないのか。
 それはGetMessage()が、WeatherService()に依存しているからです。こいつがいなかったらテストできるのです。「あーあ、いなくならないかな、WeatherService()のやつ」と思いますよね。それを実現する手法が「Dependency Injection: 依存性の注入」になります。

DIを使う例

 それではWeatherService()にいなくなってもらいます。依存性の解消です。
 もちろん完全にいなくなられると困りますから、直接WeatherService()を呼び出すのではなくインターフェースを通じて結びつけます。

依存している箇所
        public string GetMessage()
        {
            var service = new WeatherService(); // ←ここが依存している箇所
            // 中略
        }

インターフェースを作成する

 WeatherService()用のインターフェースを作って継承しましょう。

WeatherService用のインターフェース
    public interface IWeatherService
    {
        string GetTomorrowWeather();
    }
インターフェースを継承したWeatherService
    public class WeatherService: IWeatherService
    {
        public string GetTomorrowWeather()
        {
            return null;
        }
    }

コンストラクタで外から注入できるようにする

 次にこれを使用するMessenger()クラスのコンストラクタにて、外からIWeatherServiceを実体化したクラスを「注入」できるようにします。そしてそれをGetMessage()で使うように変更します。

    /// <summary>
    /// メッセージを担当するクラス
    /// </summary>
    public class Messenger
    {
        IWeatherService _weatherService;       
        /// <summary>
        /// コンストラクタ。
        /// Messengerを呼び出すのと同時に、WeatherServiceを「注入」する
        /// </summary>
        /// <param name="weatherService"></param>
        public Messenger(IWeatherService weatherService)
        {
            // ここで外から実体化したクラスを受け取る
            _weatherService = weatherService;
        }

        /// <summary>
        /// メッセージを取得する
        /// </summary>
        /// <returns></returns>
        public string GetMessage()
        {
            // コンストラクタで実体化した機能を使用する
            var tomorrowWeather = _weatherService.GetTomorrowWeather();
            // 中略
        }
    }

 これでクラス同士が直接の結びつきがなくなり、インターフェースを通しての関係性になりました。もうどこにもWeatherService()クラス自体は出てきていません。いなくなってもらいました。

テスト用の偽物(Mock)クラスを作る

 これでテストが出来るようになります。テストに必要な「偽物(Mock)」を作って外から注入してあげればいいのです。たとえば常に晴れが返ってくるSunnyWeatherService()クラスを作ってみます。もちろんこのクラスは本番のプロジェクトではなく、テストプロジェクト内で作成します。

SunnyWeatherService.cs
    /// <summary>
    /// 常に晴れが返ってくるWeatherService
    /// </summary>
    public class SunnyWeatherService: IWeatherService
    {
        public string GetTomorrowWeather()
        {
            return "晴れ";
        }
    }

偽物(Mock)を外から注入する

 先ほど作った「偽物(Mock)」クラスを外から注入します。すると、このテストはどんな時でも成功するようになります。

明日がどんな天気でも成功するテスト
        [TestMethod]
        public void GetMessage_晴れの時のテスト()
        {
            // Arrange
            var sunny = new SunnyWeatherService(); // 常に晴れが返ってくるMock
            var messenger = new Messenger(sunny);

            // Act
            var msg = messenger.GetMessage();

            // Assert
            Assert.AreEqual("明日は良い天気です。頑張りましょう", msg);
        }

 あとは曇りや雨の場合の時のテストも同様に「偽物」のWeatherService()を作成すればテストが可能になります。

 ここで「そういう偽物(Mock)を使ってテストになるのか」と思うかもしれませんが、ここではあくまでMessenger()クラスのGetMessage()のテストをしたいだけであり、このメソッドの役割は天気によってメッセージを作り出しているだけですので、これで十分テストになります。GetTomorrowWeather()が信頼が出来るかどうかは、GetTomorrowWeather()のテストで判断すればいいからです。

外から機能を注入する

 実際に使用する場合もWeatherService()Messenger()に注入して使用します。Dependency Injectionの日本語訳は「依存性の注入」ですが1 、個人的には「機能の注入」といった方がしっくりきます。メソッドの中ではインターフェースだけで実装しておいて、実際の機能を外から注入するというイメージです。

        static void Main(string[] args)
        {                       
            var weatherService = new WeatherService();
            var messenger = new Messenger(weatherService);  //呼び出す時に機能を注入

            Console.WriteLine(messenger.GetMessage());
            Console.Read();   
        }

 かつて疑問符だらけだったと冒頭で紹介した「制御の反転(inversion of control)」ですが、確かにこうしてみると、GetMessage()から呼び出していたWeatherService()が、外から中へという構造になって「反転」しています。

テスト以外のお役立ち例

 「それじゃあ、テストをしない場合は意味ないのか」と思われるかもしれませんが、それだけではありません。(テストはあった方がいいと思いますが)
 「依存していない」ということは他のコードの変更の影響を受けにくいということになります。

 たとえば気象情報を取ってくるサービスを任意で変えたいとします。今までは気象庁から取ってきていましたが、GoogleさんだったりYahooさんだったり、色んなところから取得できるようにしたいというパターンです。
 そういう時はIWeatherService()を継承してそれぞれのサービスを作成します。機能が増えた形ですが、GetMessage()のコードを変える必要はありません。

IWeatherService()を継承して各サービスの機能を実装
    public class GoogleWeatherService: IWeatherService
    {
        public string GetTomorrowWeather()
        {
            // Googleから情報を取ってくる機能
        }
    }
    public class YahooWeatherService : IWeatherService
    {
        public string GetTomorrowWeather()
        {
            // Yahooから情報を取ってくる機能
        }
    }
    public class JMAWeatherService : IWeatherService
    {
        public string GetTomorrowWeather()
        {
            // 気象庁から情報を取ってくる機能
        }
    }

 呼び出す方で、どのサービスを使うかを決定してあげる必要がありますが、GetMessage()の変更は必要ありません。

呼び出す方のMain()
        static void Main(string[] args)
        {
            IWeatherService weatherService;
            // 本事例では引数でどのWeatherServiceを使うかを決定
            switch (args[0])
            {
                case "google":
                    weatherService = new GoogleWeatherService();
                    break;
                case "yahoo":
                    weatherService = new YahooWeatherService();
                    break;
                case "jma":
                    weatherService = new JMAWeatherService();
                    break;
                default:
                    throw new Exception("想定外エラー");
            }

            var messenger = new Messenger(weatherService);  //呼び出す時に機能を注入
            Console.WriteLine(messenger.GetMessage());
            Console.Read();
        }

 もし一番最初のコードのように直接参照していたら、次のコードのように呼び出す方とGetMessage()の両方を変える必要があるため、影響が大きくなってしまいます。

        /// <summary>
        /// メッセージを取得する
        /// </summary>
        /// <returns></returns>
        public string GetMessage(string selectedServiceName)
        {
            var tomorrowWeather = "";
            switch (selectedServiceName)
            {
                case "google":
                    var googleService = new GoogleWeatherService();
                    tomorrowWeather = googleService.GetTomorrowWeather();
                    break;
                case "yahoo":
                    var yahooService = new YahooWeatherService();
                    tomorrowWeather = yahooService.GetTomorrowWeather();
                    break;
                case "jma":
                    var jmaService = new JMAWeatherService();
                    tomorrowWeather = jmaService.GetTomorrowWeather();
                    break;
                default:
                    throw new Exception("想定外エラー");
            }
            switch (tomorrowWeather)
            {
                case "晴れ":
                    return "明日は良い天気です。頑張りましょう";
                case "雨":
                    return "明日は雨みたいです。傘を忘れないように!";
                case "曇り":
                    return "明日は曇りのようです。気をつけて!";
                default:
                    throw new Exception("想定外エラー");
            }
        }

 機能を増やしたりといった他のコードの変更を受けにくい。つまり変化に強い。これがDIの特徴の一つになります。

まとめ

  • DIの理解は難しいけれど、「役に立つ」事例があると理解が進むのでそれを書いてみました。参考になれば幸いです。
  • 依存性の注入。個人的には「機能の注入」の方がしっくりきます。
  • 外から「機能を注入」するので、テストがしやすくなったり、変化に強い構造になります。

  1. 割と色んなところで訳語が分かりにくいって論争を見かけます 

20
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
saeki4n

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
20
Help us understand the problem. What is going on with this article?