問題タブ [dependency-inversion]

私は次のインターフェースを持っています

次の実装とともに

実行時に、クエリのリストがアプリケーションにロードされます。各クエリには、クエリを実行する頻度に関する情報、クエリのアラームをいつ起動するかに関する情報、およびアラームが発生したときに誰に電子メールを送信するかに関する電子メール情報が含まれています (または、設定されていない場合、アラームはイベント ログに書き込む必要があります)。 . 実行時に依存性注入を使用して、作成する ISender のインスタンス ( EmailSender または EventLogSender ) を把握し、イベントログ通知の代わりに電子メール通知を使用することを選択した場合に、クエリの適切な電子メール設定を新たに設定するにはどうすればよいですか? **注: クエリにはさまざまな通知方法を設定できます。1 つはイベントログ通知、その他はすべて電子メールのみです。

依存性逆転の原則に 100% 準拠するプログラムを作成できないことはわかっています。私たちは皆、プログラムのインスタンス化文字列によって、何も考えずに違反しています。String はデータ型ではなくクラスであるため、常に具象クラスに依存します。

これに対する解決策があるかどうか疑問に思っていました（純粋に理論的に言えば）。String は「リーク」がほとんどないブラックボックスであり、複雑なバックグラウンド アルゴリズムを備えているため、もちろん実際の実装は期待できません :)

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

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

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

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

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

依存性注入の概念はなんとか理解できましたが、依存性反転がどこで行われるのかわかりません。

たとえば、このクラスには密接な依存関係があります。

しかし、DI の概念を適用すると、次のようになります。

ただし、どのような場合でも、Manは依然としてに依存するFoodため、ここでは依存関係の逆転は見られません。

唯一の違いは、誰Foodがテーブルに置くかです。

ですから、反転原理がどこでどのように適用されるのかを明確にしてください。

DIP を使用して仮想のモジュラー C++ プロジェクトを開発したい場合。モジュール性のため、1 つの特定の機能を 1 つのライブラリに完全に実装することにしましたA。別のライブラリB(または 2 つ、または 3 つ ...) がこの機能 (ロギング メカニズムなど) を使用しています。

このインターフェイスを物理的にどこに配置すればよいですか? 一部のブロガーは、インターフェイスがユーザーに属しているため (DIP のため) 、ユーザー側(またはここ) にインターフェイスを配置する必要があることを示唆しているようです。これにより、実装をテストにリンクする必要がないため、テスト容易性も向上します。

これは、インターフェイスがないため、ライブラリ A 自体がコンパイルされないことを意味します。また、ライブラリ C がロギング機能も使用する場合、 interface も導入され、 ODRILoggerが中断されることも意味します。これは、インターフェイスのみを含む追加のパッケージ レイヤー ライブラリ D を導入することで解決できます。しかし、主な問題は残っています:

インターフェースはどこに置く？DIP に関する元の論文を読みましたが、インターフェイスをライブラリに入れるべきではないという解釈には同意できません。この論文は、開発をどのように考えるかのガイドラインとして意図されていると感じています（「ユーザーは実装者ではなくインターフェースを定義している」）。これは正しいです？依存関係逆転の原則をどのように使用しますか?

このブログ投稿では、次の動機付けのポスターによって依存関係逆転の原則が説明されました。

ポスターの意味がわかりません:ランプを壁に直接はんだ付けすることは依存関係の逆転の原則にどのように違反し、プラグは依存関係の逆転の原則にどのように従っていますか。おそらく、ランプとコンセントに関する Java または C# のスケルトン コードが役に立つかもしれません。

私はこれについて数ヶ月頭を悩ませてきましたが、それでも自分が正しい答えを持っていることを十分に納得させることができました. アプリケーションの複数のレイヤー間に依存関係があり、各レイヤーが独自のアセンブリにある、非常に典型的な状況があります。例として、アプリケーション レイヤーはリポジトリ レイヤーを使用して、非常に標準的なデータを取得します。私の質問は、抽象化 (この場合はインターフェイス) がどこにあり、その理由は何ですか? 与えられた例では、アプリケーション層またはリポジトリ層または別の抽象化アセンブリに入れる必要がありますか?

The Clean Architecture の説明の図と説明に基づいて(特にこだわっているものではありません)、すべての依存関係が内側を向くようにアプリケーション層に配置しましたが、これが正しいかどうかはわかりません。私はかなりの数の他の記事を読み、数え切れないほどの例を見てきましたが、抽象化がどこにあるべきかについて推論する方法はほとんどありません。

私はこの質問を見てきましたが、もちろん実際の答えが問題ではない場合を除き、それが私の質問に答えているとは思いません。

私は設計パターンとその周辺のもの (特にSOLIDとDependency inversionの原則など) を学んでおり、何かを失っているように見えます:

DIPルールに従って、クラス内にオブジェクトを作成するのではなく ( composition )、オブジェクト参照/ポインターをクラス コンストラクターに送信する ( aggregation )ことで、クラスの脆弱性を軽減できるはずです。しかし、これは、別の場所でインスタンスを作成する必要があることを意味します。したがって、集約を使用する 1 つのクラスがより柔軟であるほど、他のクラスはより壊れやすくなります。

どこが間違っているのか説明してください。

コードを SOLID の原則、特に依存関係の逆転の原則に従うようにしたい場合、実装が 1 つしかない場合でも、モジュールごとにインターフェイス (抽象化) を作成する必要がありますか?

私の意見では、これらの投稿によると：

http://josdejong.com/blog/2015/01/06/code-reuse/

http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

すべてのモジュールに「抽象化」を作成することは、コードが乱雑になり、YAGNI の原則に違反します。

私の経験則は、依存性注入を使用しないか、モジュールに複数の実装がない限り、モジュールのインターフェイスを作成しないことです (2 番目の実装は、データベース/サーバー/ファイル モジュールの場合の単体テスト用のモック クラスになる可能性があります)。

誰かが私のためにこれをクリアできますか? SOLID は、すべてのモジュールを注入して抽象化する必要があることを意味しますか? はいの場合、ほとんどの場合使用しないのは、ただの雑然としたものではありませんか?