制御の反転
ソフトウェア工学において、制御の反転（Inversion of Control、IoC）とは、コンピュータ・プログラムの中で、個別の目的のために書かれたコード部分が、一般的で再利用可能なライブラリによるフロー制御を受ける形の設計を指す。この設計を採用した ソフトウェアアーキテクチャは、伝統的な手続き型プログラミングと比べると制御の方向が反転している。すなわち、従来の手続き型プログラミングでは、個別に開発するコードが、そのプログラムの目的を表現しており、汎用的なタスクを行う場合に再利用可能なライブラリを呼び出す形で作られる。一方、制御を反転させたプログラミングでは、再利用可能なコードの側が、個別目的に特化したコードを制御する。
制御の反転は、プログラムのモジュール化を促進して、その拡張性を高めるために用いられ、オブジェクト指向プログラミングやその他のプログラミングパラダイムにおいて応用されている。「制御の反転」という用語はロバート・マーティンとマーティン・ファウラーによって広められた。この用語は依存性反転原則とは関係しているが異なるものである。依存性反転原則は、共有された抽象化を通じて、高次と低次の抽象化レイヤー間の結合度を下げることを示している。
従来からのプログラミングでは、フローはコードの中核部分で制御されている。IoCを使うと、これが全く変わってくる。呼び出し側は応答を得るが、いつどのようにして応答を得るかは呼び出し側が制御できない。逆に呼び出された側がいつどのようにして応えるかを決定する。
背景
「制御の反転」は計算機科学においては新しい用語ではない。マーティン・ファウラーによれば、"Inversion of Control”という用語の起源は1988年に遡る。この考え方は、階層による抽象化とよく似ている。しかし、「制御の反転」という用語は何か新しいものとして大々的に流布された。これは、そのような設計原則に開発者の目を惹きつけ、その重要性を再認識させた。Javaの世界ではこの用語が一定の認知を得た。また、特定のプログラミング言語に依存しないアーキテクチャを述べる際にも好んで使われる。
「制御の反転」がデザインパターンなのか、それともアーキテクチャの原則なのかは議論が分かれている。Shivprasad Koirala の記事では、「制御の反転」はデザインパターンとしての「依存性の注入」と組み合わせて語られており、そこでは依存性の注入がデザインパターンで、制御の反転は依存性の注入を使って実装されるとしている。一方 Mani Malarvannan の記事では、「制御の反転」は文脈化された参照 (contextualized lookup) を使ったデザインパターンとして紹介されている。サービスロケータを使ったものも同じデザインパターンだとされている。
Robert C. Martin の記事 "The Dependency Inversion Principle" では、階層による抽象化と共に論じている。彼がここで "inversion" という言葉を使ったのは、従来のソフトウェア開発手法との対比のためであった。彼が "Dependency Inversion" と呼んでいるのは、階層による抽象化でサービス群を分離することである。抽象化層を作る際には、システムの境界がどこにあるかを知ることが重要である。
「制御の反転」は「依存性の注入」と密接に関連している。依存性の注入は「制御の反転」を実装する主な手法である。
説明
従来のプログラミングでは、ビジネスロジックのフロー制御は、互いに静的結合したオブジェクト群により決められる。制御の反転を使った場合、フロー制御はプログラム実行中に構築されたオブジェクト・グラフに依存して決まる。抽象化を媒介としてオブジェクト間の相互作用の関係を定義することによって、そのような動的なフロー制御が可能となっている。この実行時結合（遅延結合）は依存性の注入あるいはサービス・ロケータ・パターンのような仕組みにより実現される。但し、制御の反転を使う場合においても、コードを直接参照する代わりに外部の設定ファイルを読んで実行すべきコードを探す仕組みにするのであれば、コンパイル中にコードを静的に関連づけることはありうる。
依存性の注入において、依存する側のオブジェクトあるいはモジュールは、その依存先のオブジェクトと、実行時において結合される。特定のどのオブジェクトがプログラム実行中にその依存関係を満たすことになるのかは、静的コード解析を行うコンパイル時には知りようがない。ここではオブジェクト間の相互作用を題材に説明したが、この原則はオブジェクト指向プログラミング以外の他のプログラミング手法にもあてはまる。
実行中のプログラムでオブジェクトどうしを相互に結び付け合うためには、結び付けられるオブジェクトどうしが互換性のあるインターフェースを持っていなければならない。例えば、クラスAはその振舞いをインターフェースIに委任しており、IはクラスBにより実装されているとする。このようにしてあれば、プログラムはAとBをインスタンス化した上で、BをAに注入できるのである。
IoC の利点と欠点
「制御の反転」には他の抽象化技法と同じように利点と欠点がある。大まかに言えば、特定のタスクは単純化されるが、アプリケーションの協調動作はより複雑になる。デビッド・ホイーラーの有名な格言に「計算機科学の全ての問題は別のレベルへのインダイレクションで解決できる」という言葉がある。この言葉の「インダイレクション」を「抽象化 (abstraction)」と間違って引用していることが多い。Kevlin Henney はこの格言の系として「…ただし、レイヤーが多すぎるせいで発生する問題を除く」という言葉もある。
同じことは「制御の反転」にも言える。Robert C. Martin の記事にあるコードを例に説明すると、最終的なコードには5つのクラスが定義されているが、手続き型プログラミングならこれを1つのメソッド（ルーチン）で実装できる。「制御の反転」は2つの実装を互いに分離するという利点があるが、同時に全体として協調動作させるときに複雑さが増す。
例
public class ServerFacade {
public Object respondToRequest(Object pRequest) {
if (!businessLayer.validateRequest(pRequest)) {
return null;
}

DAO.getData(pRequest);
return aspect.convertData(pRequest);
}}
この例は非常に恣意的に単純化してある。重要なのは、ServerFacade においてDAOオブジェクトがどういうデータを返してくるかについて、多くの仮定をしている点である。それらの仮定は全て妥当な場合もあるかもしれないが、ServerFacade と DAO の実装の結合度が高いことは否めない。「制御の反転」に従った設計では、制御を完全にDAOオブジェクトに渡してしまう。するとコードは次のようになる。
public class ServerFacade {
public Object respondToRequest(Object pRequest) {
return DAO.getData(pRequest);
}}
この場合、両方のオブジェクトは互いが何をするかについて全く仮定を設けていない。メソッドを呼び出す側とメソッドの中身を提供する側は知っている必要があるが、serverFacade は知る必要がない。これも制御の反転の重要な効果の1つである。ServerFacade は純粋に設計されたタスクを実行する（おそらく、なんらかのシステムの接続）。