依存関係逆転の原則
システム内の変更されやすい依存は抽象のみを参照すべきである
理想的にはプログラムの依存関係が具象ではなく抽象のみ参照しているものが最も柔軟なシステムである
ここの具象とは具体的な実装のことであり、抽象とはインターフェースのこと
ただしこれは現実的ではないので、将来的に変更される可能性の少ない、いわゆる枯れているモジュールについてはその限りではない
例えば標準ライブラリの多くのコードは具象だし、それを無理やりインターフェース経由にすることは無駄である
したがってシステム内の変更されやすい依存から抽象化していくのが現実的なプラクティスとなる
原則実現のためのコーディングレベルのプラクティス
変化しやすい具象クラスを参照せず、抽象インターフェースを参照すること
変化しやすい具象クラスを継承しない
静的型付けオブジェクト指向言語においては注意が必要
avashe.icon個人的にはなるべくインターフェースを使って継承はよほどの必然性がない限り使わなければよいと思う
具象関数をオーバーライドしない
あるクラスParentの具象関数が巨大なクラスBigをimportし使っている場合、ParentをオーバーライドしたサブクラスChildは、Bigを使用していないにもかかわらずモジュールのインポート上、Bigに依存していることになる
BigがビルドできなければChildもビルドできないので、独立で開発しづらくなる
そこでParentとChildのインターフェースであるAbstractを追加し、ParentはAbstractとBigをインポート、ChildはAbstractだけをインポートするように改修すればよい
変化しやすい具象を名指しで参照しない
これは本原則を言い換えただけ
avashe.iconと本書は言っているが、それなら猶更依存関係逆転の原則という名称は直感的じゃないし失敗名称だと思う ぶっちゃけ、オブジェクト指向プログラミングの仕様に引っ張られた命名なだけで本質的じゃないよね
geminiくん曰くそれは「コードをどう書くべきか（How）」としてはわかりやすいが、「アーキテクチャ的な効果（Why）」を重視するのであれば、「安定抽象依存の原則」や「詳細プラグイン化の原則」はどうだろうとのことです
オブジェクト生成のためにコンストラクタを呼ぶと具象定義を参照してしまうので、代わりにオブジェクト生成用のクラス(ファクトリークラス)とインターフェースを用意し、ファクトリークラスのインターフェース経由でオブジェクトを生成する。ファクトリークラスで生成されるオブジェクトのインターフェースも作っておけば、オブジェクトを直接参照せず操作することができる。
複数個オブジェクトを生成する場合にこれが利用できる
ほとんどのシステムには、依存関係逆転の原則（DIP）を満たさない具象コンポーネントが少なくともひとつは存在する Abstract Factoryパターンの場合、ファクトリークラス自体を作る呼び出し手がどこかで必要になるが、これはmain関数が担当する
多くの場合main関数が具象コンポーネントになる
プログラムのエントリポイントで各種コンポーネントをセットアップするロジックが走るはず、そのときに具象的なファクトリークラスを作成し、ビジネスロジック担当クラスに渡してやるとよい。ビジネスロジック担当クラスはそのファクトリークラスをインターフェース型で扱えば具象定義に依存せず済む。
具象コンポーネントはなるべく少なくすること