依存関係反転の原則を適用しない場合

現在、SOLIDを把握しようとしています。したがって、依存関係反転の原則は、任意の2つのクラスが直接ではなく、インターフェースを介して通信することを意味します。例：class Aメソッドがあり、typeのオブジェクトへのポインターを予期するclass B場合、このメソッドは実際にtypeのオブジェクトを予期する必要がありますabstract base class of B。これは、オープン/クローズにも役立ちます。

私が正しく理解していれば、私の質問は、これをすべてのクラスの相互作用に適用するのが良い習慣であるか、レイヤーの観点から考えてみるべきですか？

私が懐疑的である理由は、この原則に従うためにいくらかの代価を払っているからです。たとえば、featureを実装する必要がありますZ。分析後Z、機能はA、Bおよびで構成されていると結論付けCます。私が作成ファサードクラスはZ、それは、インタフェースを介して、クラスを使用していますA、BとC。私は実装をコーディングを開始し、いくつかの点で私は、そのタスクを実現するZ実際の機能で構成されA、BそしてD。次に、Cインターフェイス、Cクラスプロトタイプを破棄し、Dインターフェイスとクラスを個別に記述する必要があります。インターフェイスがなければ、クラスのみを置き換える必要があります。

_{つまり、何かを変更するには、1。呼び出し元2.インターフェイス3.宣言4.実装を変更する必要があります。Python直接結合実装では、実装のみを変更する必要があります。}

多くの漫画やその他のメディアでは、善と悪の勢力は、キャラクターの肩に座っている天使と悪魔によって描かれていることがよくあります。ここでの話では、善悪の代わりに片方の肩にソリッドがあり、もう片方にYAGNI（あなたは必要ないでしょう！）があります。

SOLIDの原則を最大限に活用することは、巨大で複雑な、超構成可能なエンタープライズシステムに最適です。より小規模な、またはより具体的なシステムの場合、すべてを途方もなく柔軟にすることは適切ではありません。物事を抽象化するために費やす時間が有益であることが証明されないからです。

具体的なクラスの代わりにインターフェイスを渡すと、たとえば、ファイルからの読み取りをネットワークストリームに簡単に交換できることを意味する場合があります。しかし、ソフトウェアプロジェクトの偉大な量のために、柔軟性のようなものはただではない、これまで必要とされようとして、そしてあなたにもちょうど、具体的なファイルのクラスを渡し、その日それを呼び出すと、あなたの脳細胞を惜しまかもしれません。

ソフトウェア開発の技術の一部は、時間が経つにつれて変化する可能性のあるものとそうでないものをよく理解していることです。変更される可能性のあるものについては、インターフェイスおよびその他のSOLIDの概念を使用してください。そうでないものについては、YAGNIを使用して、具体的な型を渡し、ファクトリクラスを忘れ、すべてのランタイムフックアップと構成などを忘れ、SOLID抽象化の多くを忘れます。私の経験では、YAGNIのアプローチはそうでない場合よりもはるかに頻繁に正しいことが証明されています。

素人の言葉で：

DIPの適用は簡単で楽しいものです。最初の試行で設計を正しく行わなかっただけでは、DIPを完全に放棄する十分な理由にはなりません。

• 通常、IDEはそのようなリファクタリングを支援します。一部の実装では、既に実装されているクラスからインターフェイスを抽出することさえできます。
• 初めてデザインを正しくすることはほとんど不可能です
• 通常のワークフローでは、開発の最初の段階でインターフェイスを変更して再考する必要があります
• 開発が進化するにつれて成熟し、インターフェイスを変更する理由が少なくなります
• 高度な段階では、インターフェース（設計）は成熟し、ほとんど変わりません。
• その瞬間から、あなたはアプリがスケールアップするために開かれているので、あなたは利益を享受し始めます。

一方、インターフェイスとOODを使用したプログラミングは、時には時代遅れのプログラミング技術に喜びを取り戻すことができます。

複雑さを増すと言う人もいますが、オポサイトは真実だと思います。小さなプロジェクトでも。テスト/モック作成が簡単になります。caseステートメントまたはネストされてifsいる場合、コードが少なくなります。循環的な複雑さを軽減し、新鮮な方法で考えさせます。プログラミングを実世界の設計と製造により似たものにします。

意味のある場合は、依存関係の反転を使用します。

極端な反例の1つは、多くの言語に含まれる「文字列」クラスです。これは、基本的な文字の配列である基本的な概念を表します。このコアクラスを変更できると仮定すると、内部状態を他のものと交換する必要がないため、ここでDIを使用する意味はありません。

モジュール内で使用されるオブジェクトのグループが他のモジュールに公開されていないか、どこでも再利用されていない場合、おそらくDIを使用するだけの価値はありません。

私の意見では、DIが自動的に使用されるべき場所は2つあります。

1. 拡張用に設計されたモジュール内。モジュールの全体的な目的がそれを拡張して動作を変更することである場合、DIを最初から焼き付けることは完全に理にかなっています。

2. コードの再利用を目的としてリファクタリングしているモジュール内。おそらく、何かをするためにクラスをコーディングし、後でリファクタリングを行うと、そのコードを他の場所で活用できるため、そうする必要があることに気づくでしょう。これは、DIおよびその他の拡張性の変更の優れた候補です。

ここでのキーは、複雑さが増すため必要な場所で使用し、技術要件（ポイント1）または定量的コードレビュー（ポイント2）で必要性を測定することです。

DIは素晴らしいツールですが、他の*ツールと同様に、使いすぎたり誤用されたりする可能性があります。

_{*上記のルールの例外：往復のこぎりは、あらゆる仕事に最適なツールです。問題が解決しない場合は、それを削除します。永久に。}

元の質問には、DIPの要点が欠けているように思えます。

私が懐疑的である理由は、この原則に従うためにいくらかの代価を払っているからです。たとえば、機能Zを実装する必要があります。分析後、機能Zは機能A、B、およびCで構成されていると結論付けます。インターフェイスを介してクラスA、B、およびCを使用するfascadeクラスZを作成します。実装と、ある時点でタスクZが実際に機能A、B、Dで構成されていることに気付きます。Cインターフェイス、Cクラスプロトタイプを破棄し、個別のDインターフェイスとクラスを記述する必要があります。インターフェイスがなければ、クラスだけを置き換える必要があります。

DIPを真に活用するには、最初にクラスZを作成し、クラスA、B、およびC（まだ開発されていない）の機能を呼び出すようにします。これにより、クラスA、B、CのAPIが得られます。次に、クラスA、B、Cを作成して詳細を入力します。クラスZが必要とするものに完全に基づいて、クラスZを作成するときに必要な抽象化を効果的に作成する必要があります。クラスA、B、またはCを作成する前に、クラスZをテストすることもできます。

DIPでは、「高レベルのモジュールは低レベルのモジュールに依存するべきではありません。両方とも抽象化に依存する必要がある」ということを覚えておいてください。

クラスZに必要なものと、クラスZが必要なものを取得する方法を決定したら、詳細を入力できます。もちろん、クラスZに変更を加える必要がある場合もありますが、99％の場合はそうではありません。

Zが記述される前にA、B、Cが必要であることがわかったため、クラスDが存在することはありません。要件の変更はまったく別の話です。

短い答えは「ほとんどない」ですが、実際には、DIPが意味をなさない場所がいくつかあります。

1. オブジェクトを作成することが仕事である工場または建築業者。これらは基本的に、IoCを完全に包含するシステムの「リーフノード」です。ある時点で、何かが実際にオブジェクトを作成する必要があり、それを行うために他の何かに依存することはできません。多くの言語では、IoCコンテナがあなたのためにそれをすることができますが、時々あなたは昔ながらの方法でそれをする必要があります。

2. データ構造とアルゴリズムの実装。一般に、これらの場合、最適化する際の顕著な特性（実行時間や漸近的な複雑さなど）は、使用されている特定のデータ型に依存します。ハッシュテーブルを実装している場合、リンクリストではなく、ストレージ用の配列を操作していること、そして配列を適切に割り当てる方法を知っているのはテーブル自体だけであることを本当に知る必要があります。また、可変配列を渡して、その内容をいじることによって呼び出し元にハッシュテーブルを分割させたくありません。

3. ドメインモデルクラス。これらはビジネスロジックを実装し、（ほとんどの場合）1つのビジネス用のソフトウェアのみを開発しているため、（ほとんどの場合）1つの実装を持つことだけが理にかなっています。けれども、いくつかのドメインモデルクラスは、他のドメインモデルクラスを使用して構築される可能性があります、これは一般的に、ケースバイケースであることを行っています。ドメインモデルオブジェクトには、便利にモックできる機能が含まれていないため、DIPにはテスト容易性や保守性の利点はありません。

4. 外部APIとして提供され、他のオブジェクトを作成する必要があるオブジェクト。その実装の詳細を公開したくない場合。これは、「ライブラリの設計はアプリケーションの設計とは異なります」という一般的なカテゴリに分類されます。ライブラリまたはフレームワークは、DIを内部で自由に使用できますが、最終的には実際の作業を行う必要があります。そうでない場合、あまり有用なライブラリではありません。ネットワークライブラリを開発しているとしましょう。コンシューマーがソケットの独自の実装を提供できるようにすることは本当に望ましくありません。内部でソケットの抽象化を使用することもできますが、呼び出し元に公開するAPIは独自のソケットを作成します。

5. ユニットテスト、およびテストダブル。偽物とスタブは、1つのことを実行し、単純に実行することになっています。依存性注入を行うかどうかを心配するほど複雑な偽物がある場合は、おそらくあまりにも複雑です（おそらく、あまりにも複雑すぎるインターフェイスを実装しているためです）。

もっとあるかもしれません。これらはやや頻繁に見られるものです。

DIPを非常に小さなレベルで適用している可能性がありますが、値を提供していません。

• C / CImplまたはIC / Cペアがあり、そのインターフェイスの実装は1つだけである
• インターフェイスと実装の署名が1対1に一致する（DRY原則に違反）
• CとCImplを同時に頻繁に変更します。
• Cはプロジェクトの内部にあり、プロジェクトの外部でライブラリとして共有されることはありません。
• Visual StudioのEclipse / F12のF3に実際のクラスの代わりにインターフェイスが表示されることにイライラしている

これが表示されている場合は、ZがCを直接呼び出してインターフェイスをスキップする方が良いかもしれません。

また、依存性注入/動的プロキシフレームワーク（Spring、Java EE）によるメソッドデコレーションは、真のSOLID DIPとは異なります。これは、その技術スタックでのメソッドデコレーションの動作の実装の詳細に似ています。Java EEコミュニティは、これまでのようにFoo / FooImplのペアを必要としないことを改善と見なしています（参照）。対照的に、Pythonは関数装飾を第一級の言語機能としてサポートしています。

このブログ投稿も参照してください。

依存関係を常に反転させると、すべての依存関係が逆さまになります。つまり、依存関係の結びつきがある厄介なコードから始めた場合、それはまだ（本当に）持っているものであり、逆になっているだけです。ここで、実装を変更するたびにインターフェースも変更する必要があるという問題が発生します。

依存関係の逆転のポイントは、物事を混乱させる依存関係を選択的に逆転させることです。AからBからCに移動する必要があるものはまだそうします。CからAに移動していたものは、現在AからCに移動します。

結果は、サイクルのない依存グラフ、つまりDAGになります。このプロパティをチェックし、グラフを描くさまざまな ツールがあります。

詳細な説明については、この記事を参照してください。

依存関係逆転の原則を正しく適用することの本質はこれです：

依存するコード/サービス/…をインターフェイスと実装に依存します。インターフェイスは、それを使用してコードの専門用語の依存関係を再構築し、実装はその基礎となる技術の観点から実装します。

実装はそのままです。しかし、インターフェースには現在、異なる機能があり（そして、異なる専門用語/言語を使用しています）、使用するコードができることを記述しています。そのパッケージに移動します。インターフェイスと実装を同じパッケージに配置しないことにより、依存関係（の方向）は、ユーザー→実装から実装→ユーザーに反転します。