意味：
高レベルのモジュールは、低レベルのモジュールに依存してはなりません。どちらも抽象化に依存する必要があります。抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。
問題の起源：クラスAはクラスBに直接依存します。クラスAを変更してクラスCに依存する場合は、クラスAのコードを変更することで達成する必要があります。このシナリオでは、クラスAは一般に複雑なビジネスロジックを担当する高レベルモジュールです。クラスBとクラスCは、基本的な原子動作を担当する低レベルモジュールです。クラスAが変更された場合、プログラムに不必要なリスクをもたらします。
解決策：クラスAを変更してインターフェイスIに依存し、クラスBとクラスCは各インターフェイスIを実装します。クラスAはインターフェイスIを介してクラスBまたはクラスCに間接的に接触します。これにより、クラスAを変更する可能性が大幅に減少します。
依存関係の原則は、抽象的なものが詳細の変動よりもはるかに安定しているという事実に基づいています。要約に基づいて構築されたアーキテクチャは、詳細に基づいて構築されたアーキテクチャよりもはるかに安定しています。 Javaでは、要約とはインターフェイスまたは抽象クラスを指し、詳細は特定の実装クラスです。インターフェイスまたは抽象クラスを使用する目的は、特定の操作を伴わずに仕様と契約を策定し、完了のために実装クラスに詳細を提示するタスクを引き渡すことです。
依存関係の反転の原理の中心的なアイデアは、インターフェイス指向のプログラミングです。インターフェイス指向のプログラミングが実装指向プログラミングよりも優れている場所を説明するために、例を使用します。シーンはこのようなものです。母親は子供に物語を語ります。彼女が彼女に本を与える限り、彼女は本に従って彼女の子供に物語を語ることができます。
例：
違法依存の反転
パブリッククラスの学生{public void read（book book）{system.out.println（ "学生が読み始める："+book.getname（））; }} public class book {public string getname（）{return "book"; }}
学生がWebページを読む必要がある場合、学生クラスを変更する必要があります。これは非常に友好的でないデザインです。依存の反転の原則に準拠した例を見てみましょう。
public Interface Person {public void read（reader reader）; } public interface reader {public string getname（）; }パブリッククラスの学生実装者{@Override public void read（reader reader）{system.out.println（ "学生スタートリーディング："+reader.getName（））; }} public class book実装reader {public string getname（）{return "book"; }} public class webサイトはreader {public string getname（）{return "webページ"; }} public class test {public static void main（string [] args）{person sustent = new Student（）; Student.read（new Book（））; Student.read（new Webサイト（））; }}
読み取り方法では、インターフェイスをパラメーターとして使用します。
要約：
1.各クラス、または両方のインターフェイスと抽象クラスのインターフェイスまたは抽象クラスを使用することが最善です。
2。変数宣言は、できればインターフェイスまたは抽象クラスであることが好ましい。
3。継承中の代替の原則を遵守します。