制御の反転
そもそも、コンピュータ科学ないしはソフトウェア工学などの観点から、これは何か斬新なアイディアというわけではない。IoC という言葉を広めたマーティン・ファウラー自身も起源は1988年に遡るとしている。この考え方は、階層による抽象化とよく似ている。それが21世紀になって IoC という略称とともに広がったのは、Java など新しい環境が広く使われるようになり、そのプログラマも増えたといったような背景がある。これは、そのような設計原則に開発者の目を惹きつけ、その重要性を再認識させた。Javaの世界ではこの用語が一定の認知を得た。また、特定のプログラミング言語に依存しないアーキテクチャを述べる際にも好んで使われる。
制御の反転がデザインパターンなのか、それともアーキテクチャの原則なのかは議論が分かれている。Shivprasad Koirala の記事では、「制御の反転」はデザインパターンとしての「依存性の注入」と組み合わせて語られており、そこでは依存性の注入がデザインパターンで、制御の反転は依存性の注入を使って実装されるとしている。
「制御の反転」には他の抽象化技法と同じように利点と欠点がある。大まかに言えば、特定のタスクは単純化されるが、アプリケーションの協調動作はより複雑になる。デビッド・ホイーラーの有名な格言に「計算機科学の全ての問題は別のレベルへのインダイレクションで解決できる」という言葉がある。この言葉の「インダイレクション」を「抽象化 (abstraction)」と間違って引用していることが多い。Kevlin Henney によるこの格言の系(corollary)として「...ただし、レイヤーが多すぎるせいで発生する問題を除く」という言葉もある。
同じことは「制御の反転」にも言える。Robert C. Martin の記事にあるコードを例に説明すると、最終的なコードには5つのクラスが定義されているが、手続き型プログラミングならこれを1つのメソッド(ルーチン)で実装できる。「制御の反転」は2つの実装を互いに分離するという利点があるが、同時に全体として協調動作させるときに複雑さが増す。
一方 Mani Malarvannan の記事では、「制御の反転」は文脈化された参照 (contextualized lookup) を使ったデザインパターンとして紹介されている。サービスロケータを使ったものも同じデザインパターンだとされている。
ロバート C. マーチン(英語版) の記事 "The Dependency Inversion Principle" では、階層による抽象化と共に論じている。彼がここで "inversion" という言葉を使ったのは、従来のソフトウェア開発手法との対比のためであった。彼が "Dependency Inversion" と呼んでいるのは、階層による抽象化でサービス群を分離することである。抽象化層を作る際には、システムの境界がどこにあるかを知ることが重要である。
制御の反転は依存性の注入と密接に関連している。依存性の注入は制御の反転を実現する有効な手法の一つである。