プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

DIとDIPとIoC

この3つの用語はなんとなく名前が被っている上に同じ文脈で登場することが多いため、初学者は混乱しやすい。

なにが違うのか、Dependency Injectionパターンを中心に関係性を整理してみよう。

f:id:hogehoge666:20200821205250p:plain


Dependency Injectionパターン

DIパターンについてはこちらの記事で詳細に説明しているので参照いただきたい。

architecting.hateblo.jp


Inversion of Control

DIパターンはもともとIoCの実現方式の1つとして登場した。

IoCとは制御が逆転するシステムアーキテクチャ設計である。

古典的制御

例えばUIから文字列を受け取って処理するソフトウェアを考えてみる。これを古典的なCLIプログラムとして実装すると以下のようになる。

1. プログラムは入力を促すCLIメッセージを出力する
2. プログラムは標準入力へ入力が来るのを待つ
3. プログラムは標準入力の内容を処理する

制御の起点はプログラムであり、プログラムから一時的に標準入力へ制御が移り、その後またプログラムに戻っている。

現代的制御

一方、現代的なGUIアプリケーションでは以下のようになる。

1. フレームワークがGUIが表示する。
2. フレームワークはGUIに入力が来るのを待つ。
3. GUIに入力が来るとフレームワークはプログラムを呼び出す。
4. プログラムは処理を実施する。

制御の起点はフレームワークであり、一時的にプログラムに制御が移り、その後またフレームワークに戻っている。制御の流れが古典的なCLIプログラムと逆転している。これがIoCである。

GUIに限らずフレームワークを利用した開発ではIoCは頻出するアーキテクチャだ。フレームワークを利用した開発が主流となった現在ではIoCは当たり前のこととなっている。

IoCの新たな適用領域

再利用可能なモジュールを組み合わせてソフトウェアを構築することが一般化していく中で、IoCの新たな側面が脚光を浴びるようになってきた。

再利用可能なモジュール同士は開発時点で互いのことを全く知らない。その互いのことを全く知らないクラス同士をどのように組み合わせるべきかという課題に対してもIoCの実現方式が有効だったのだ。

IoCの複数ある実現方式の中で特にGood Practiceだと思われたのがDIパターンだ。当初、DIパターンという名前がなかったためIoCと呼ばれていたがこの新しい用途は制御の逆転が主目的ではないことや他のIoC実現方式と見分けがつかないことから混乱が生じた。そこでMartin Fowler氏が整理してDependency Injectionパターンと命名した。


Dependency Inversion Principle

DIPはSOLID原則の1つでモジュール間の依存関係を適正な姿にコントロールすることを要求する設計原則だ。上位クラスで下位の具象クラスに依存してはならないと定めている。SOLID原則についてはこちらの記事を参照いただきたい。

architecting.hateblo.jp

現実には開発の中で上位クラスが下位クラスに依存するような状況は発生してしまうことがある。DIパターンはクラス間の依存関係を逆転させる効果があるのでこのような状況で依存関係を最適化するために利用できる。DIパターンはDIPの実現に非常に有用なツールと言える。

両方とも頭文字を取るとDIやDIPなので初学者は「言葉がちょっと違うだけで同じものなんじゃないか?」と勘違いしそうになる。違いをしっかり理解しておきたい。


まとめ

  • Inversion Of Control

  • Dependency Injectionパターン

    • IoCの実現方式の1つ。
  • Dependency Inversion Principle

    • モジュール間の依存関係を適正な姿にコントロールすることを要求する設計原則。
    • 依存関係を逆転させたいときにDependency Injectionパターンが利用できる。