oop - 「依存関係の逆転」と「インターフェイスへの設計」は同じ原則ですか?

Question

「依存性逆転の原則」(DIP) と「インターフェースへの設計の原則」は同じ原則を表していますか? そうでない場合、違いは何ですか？

編集

コンテキストを明確にし、少し絞り込むために: インターフェイスとは、Javainterfaceや C++ の純粋な抽象基本クラスのようなプログラム インターフェイスを意味します。他の「契約」は関係ありません。

Answer 1

私の意見では、この質問にうまく答えているので、これに非常によく似た別の質問についてDerek Greerを引用して引用したかっただけです。

‌<em>「依存関係逆転の原則が言及していないのは、インターフェイス (例: MyService → [ILogger ⇐ Logger]) を使用して依存関係を抽象化する単純な方法です。」

これにより、依存関係の特定の実装の詳細からコンポーネントが分離されますが、消費者と依存関係 (例: [MyService → IMyServiceLogger] ⇐ Logger) の間の関係が逆転することはありません。」

Answer 2

依存関係の逆転により、上位レベルのモジュールが下位レベルのモジュールに依存しないようになります。したがって、アプリケーション ロジックはビジネス モデルやビジネス ロジックに依存しません。関心事の明確な分離があります。

この原則では、ビジネス層が実装する必要があるインターフェイスをアプリケーションが定義し、所有することが規定されています。このように、ビジネス層はアプリケーションの定義済みインターフェースに依存します。したがって、依存関係は逆になります。

これを拡張すると、3 つのアプリケーションがあり、それぞれがビジネス層によって実装された独自のインターフェイスを持ち、ビジネス層が変更される可能性があり、それらが必要に応じてインターフェイスを実装している限り、アプリケーションは賢明ではありません。

この原則の良い Java の例と、そのようなプロジェクトがどのように構成されるかは、私の Web サイトhttp://www.jeenisoftware.com/maven-dip-principle-example/にあります。

依存関係の逆転は、設計からインターフェースまでということではなく、サービスへの実装に関するものです。つまり、一種のサービス指向の設計パターンです。

Answer 3

インターフェースへの設計 (コントラクトによる設計のバリアントとして) は、依存関係の逆転をサポートします。どちらもカップリングを減らします。でも：

• インターフェイスへの設計と DBC は、オブジェクトがどのように作成されるかについて何も言いません (例: DIP、抽象ファクトリ、ファクトリ メソッド)。
• 依存関係の逆転(依存関係の注入) は一般にインターフェイスに依存しますが、クラスの設計よりもオブジェクトのライフサイクルに焦点を当てています。必要に応じて抽象基本クラスで DIP を使用できるため、純粋なインターフェイスに専念する必要はありません。

アプローチは互いに補完し合う傾向があります。

Answer 4

「契約による設計」と「依存性注入」は非常に密接に関連していますが、抽象化のレベルが異なります。「契約による設計」は非常に一般的な設計原則であり、さまざまな手法でサポートできます。Java のようなクラス システムを持つ言語では、インターフェイスを使用して具体的なクラスの依存関係を回避することが 1 つの手法です。「依存性注入」は、関数へのインターフェースの存在に依存することが多い別の手法です (ただし、常にそうする必要はありません - 言語によって異なります)。「依存性注入」は「契約による設計」の原則をサポートしていると思います。