依存関係逆転の原則
- 上位のモジュールは下位のモジュールに依存してはならない
- どちらのモジュールも「抽象」に依存すべきである
- 「抽象」は実装の詳細に依存してはならない
- 実装の詳細が「抽象」に依存すべきである
- 従来の開発手法の目標の一つは上位モジュールから下位モジュールの呼び出し方を定義したプログラムの階層構造を作ることだった
- 上手に設計されたオブジェクト指向プログラムの構造は従来の手続き型で見慣れた依存構造を逆転したものになる
- アプリケーションの存在理由を決定づけているのは上位のモジュールであるにも関わらず、上位モジュールが下位モジュールに依存すると下位モジュールの変更が直接上位モジュールに影響を与え、上位モジュールまで変更を余儀なくされる
- 立場的にアプリケーションの方針を上位レベルのモジュールが実装の詳細を担当している下位レベルのモジュールに影響を与えるべきである
「抽象」に依存する
- 依存関係逆転の原則を一言で言うと「抽象に依存せよ」という経験則だと言える
- 荒削りではあるが的確にDIPの本質を言い当てている
- この原則はプログラムは具体的なクラスに依存してはいけないこと、プログラム内の関係は全て抽象クラスかインターフェースで終結すべきであることを提言している
- この経験則によると:
- 具体的なクラスへのポインタやリファレンスを保持するような変数があってはならない
- 具体的なクラスから派生するクラスがあってはならない
- 基本クラスで実装されているメソッドを上書きしてしまうようなメソッドがあってはならない
結論
- 伝統的な手続き型のプログラミングでは方針が実装の詳細に依存する構造になる
- そうなると「方針」が詳細の変更に影響されるので好ましくない
- オブジェクト指向プログラミングでは方針と実装の詳細を「抽象」に依存させることで悪しき依存関係を逆転させることができる
- 依存関係の逆転が織り込まれていることこそ、良いオブジェクト指向設計の顕著な特徴と言える
- 依存関係が逆転していればオブジェクト指向設計と言え、依存関係が逆転していなければ手続き型設計
- 依存関係逆転の原則は、オブジェクト指向技術の様々な利益を享受するために必要不可欠な下位レベルのメカニズム
- 変更に耐えられるコードを構築するためにも非常に重要
- この原則を適用すれば抽象と実装の詳細は完全に切り離され、コードを保守するのがずっと楽になる