9

Dependency Inversion Principle (SOLID 原則の 1 つ) と一般的な 'Code to Interfaces' または Separated Interface パターンの違いを理解できません。それらはすべて、下位レベルと上位レベルのモジュールを分離するための抽象化レイヤーの作成を提唱しています。

DI の原則は、上位モジュールと下位モジュールの間で対話するためのインターフェイスの作成を想定していますが、インターフェイスが上位レベル パッケージの一部でなければならないことも主張しています。
なぜこれは下位レベルではなく上位レベルの一部である必要があるのですか? その動作を公開しているのは下位レベルなので、デカップリング インターフェイスは下位レベルの一部であるべきではありませんか? 同じ下位レベルに依存する上位レベルのモジュールが複数ある場合はどうなりますか?

または、
すべてのインターフェイスを配置する別のパッケージを作成して、上位レベルと下位レベルの両方で使用できるようにしてみませんか? (これは、Separated Interfaces パターンで想定されています。)

私のジレンマは、相対的な使用法と利点、またはそれらのそれぞれを理解できないことです。

Derek Greer または Robert Martin の記事を引用しないでください。私はそれらの記事を読みましたが、依然として混乱が続いています。

4

3 に答える 3

4

Dependency Inversion は、Spring、Guice などの依存性注入フレームワークのビルディング ブロックである概念です。つまり、コンポーネントはその依存性を検索するのではなく、外部から依存性を注入する必要があるということです。コンポーネントの依存関係は、インターフェイスまたは別のクラスにすることができます。依存関係がインターフェースである場合、コンポーネントはさまざまな実装で柔軟に動作します。

例を見てみましょう: 誰かが、いくつかのサービス呼び出しを行う必要があるコンポーネントを書いているとしましょう。コンポーネント開発者が、サービス呼び出しは常に HTTP を使用して行う必要があると考える場合、HTTP クライアントを依存関係にします。これにより、コンポーネント ユーティリティが HTTP ベースのサービスのみを呼び出せるように制限されます。ただし、同じ開発者がたとえば GenericExternalServiceInvoker というインターフェイスを作成し、2 つの実装を実装した可能性があります。インターフェイスを使用することで、コンポーネント開発者は、より幅広い方法で役立つコンポーネントを作成できるようになりました。

上記の例では、DI があると仮定しました。依存関係が外部から注入されていたためです。コンポーネント開発者は、別の設計上の選択を行い、コード内で HTTP クライアントをインスタンス化することができた可能性があります。そのため、必要に応じてコンポーネントのユーザーがその動作を変更し、HTTP 以外のものを使用することが難しくなります。

したがって、要約すると、DI を使用して、コンポーネントがその依存関係に固定的に依存しないようにする必要があります。コンポーネントの依存関係をインターフェースにすることで、コンポーネントにさらなる柔軟性が組み込まれます。2 番目の原則であるコードからインターフェイスへは、開発者が具体的なクラスではなく依存関係としてインターフェイスを選択するための指針となります。

于 2013-12-20T09:28:09.137 に答える
1

依存性注入とインターフェースへのプログラミングの違いは何ですか？

インターフェイスへのプログラミング

インターフェイスへのプログラミングは、パブリック インターフェイスを介してさまざまなオブジェクトが相互に対話するソフトウェア開発の実践です。これにより、コードベースへの変更を最小限に抑えて、あるインターフェイス実装から別のインターフェイス実装に簡単に切り替えることができ、コードの再コンパイルを回避することさえできるため、柔軟性が向上します。

依存性注入

依存性注入は、開発者ではなくフレームワークによってオブジェクト インスタンスを作成できるようにするメカニズムです。ほとんどの場合、オブジェクトを使用できるようにするには、いくつかの追加オブジェクト (依存関係と呼ばれる) が既に存在し、現在のオブジェクトのコンストラクターまたはそのオブジェクトのプロパティに渡される必要があります。依存性注入は、必要なオブジェクトを構築する (注入する) ときに、フレームワークがこれらを提供および設定できるようにするメカニズムです。通常、フレームワークは、外部構成またはコード検査に基づいて何をすべきかを認識しています。 依存性注入パラダイムは、インターフェイスへのプログラミングに依存しています
依存関係は通常、パブリック インターフェイスを介して公開されるためです (これが最初に説明した理由です)。したがって、構成の変更のみに基づいて、さまざまな実装を使用できます。これにより、アプリケーションの特定の側面をテストするときに、オブジェクトのモック セットアップを簡単に使用できるようになります。

通常、依存性注入は制御メカニズムの反転と呼ばれます。これは、フレームワーク (アプリケーション コードを意味する) が手動でインスタンス化 (開発者によって行われる) ではなく、オブジェクトの作成を処理するようになるためです。

aknonのコメントによると:

依存性注入は依存性反転と同じですか?

必ずしもそうではありません。依存関係の逆転は、2 つのオブジェクト間の依存関係を逆転させるリファクタリング プロセスとも呼ばれます。たとえば、以前のリファクタリングclass Aに依存している可能性があり、その後は代わりに依存する必要がある場合があり、依存関係が逆転します。依存性注入は、明示的にコードを記述せずに依存性を提供するメカニズムです。class B class Bclass A

アップデート

依存関係の逆転という用語の詳細については、Rich Newman のこの記事を読むことをお勧めします。これは、Microsoft Smart Client Software Factory テクノロジ (現在は古いもの) に対処する一連の記事の一部ですが、この記事は十分に中立的であり、それ自体で成り立つことができます。

以下も参照してください。

于 2013-12-20T09:31:51.810 に答える