依存性注入を使用することの欠点は何ですか？[閉まっている]

私が知りたいのですが、ここでの仕事と私たちのリード開発者の一人で、パターンとしてDIを導入しようとしている：どのような-もしあれば-あるマイナス面依存性の注入パターンを使用するには？

ここでは、トピックに関する主観的な議論ではなく、可能な限り完全なリストを探していることに注意してください。

明確化：私は依存性注入パターン（Martin Fowlerによるこの記事を参照）について話しているのですが、特定のフレームワークではなく、XMLベース（Springなど）でもコードベース（Guiceなど）でも、「自己ロール」 。

編集：ここで/ r / programmingを進行中のいくつかの素晴らしいディスカッション/怒り/討論。

いくつかのポイント：

• 責任がより分離されるため、DIは通常、クラスの数を増やすことによって複雑さを増加させますが、これは必ずしも有益ではありません
• コードは、（ある程度）使用する依存関係注入フレームワーク（または、より一般的には、DIパターンの実装を決定する方法）に結合されます。
• タイプ解決を実行するDIコンテナーまたはアプローチは、通常、実行時に若干のペナルティを伴います（ごくわずかですが、そこにあります）

一般に、デカップリングの利点により、各タスクが読みやすく、理解しやすくなりますが、より複雑なタスクのオーケストレーションはより複雑になります。

オブジェクト指向プログラミング、スタイルルール、およびその他すべてについてよくある基本的な問題。非常に一般的ですが、実際には、あまりに多くの抽象化を実行し、あまりにも多くの間接化を追加し、一般に優れた手法を過度に、間違った場所に適用する可能性があります。

適用するすべてのパターンまたはその他の構成は複雑になります。抽象化と間接化は情報を分散させ、時には無関係な詳細を邪魔にならないようにしますが、同じように時々何が起こっているのか正確に理解することを難しくします。適用するすべてのルールは柔軟性に欠け、最適なアプローチである可能性があるオプションを除外します。

ポイントは、その仕事を行い、堅牢で、読みやすく、保守可能なコードを書くことです。あなたはソフトウェア開発者であり、象牙の塔ビルダーではありません。

関連リンク

http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

http://www.joelonsoftware.com/articles/fog0000000018.html

おそらく、最も単純な依存性注入の形式（笑わないでください）がパラメーターです。依存コードはデータに依存しており、そのデータはパラメーターを渡すことによって注入されます。

はい、それはばかげているし、依存性注入のオブジェクト指向のポイントに対処していませんが、関数型プログラマーは（ファーストクラスの関数がある場合）これが必要な唯一の種類の依存性注入であることを教えてくれます。ここでのポイントは、些細な例を取り、潜在的な問題を示すことです。

この単純な従来の関数を見てみましょう-C ++構文はここでは重要ではありませんが、なんとかして綴る必要があります...

void Say_Hello_World ()
{
  std::cout << "Hello World" << std::endl;
}

「Hello World」というテキストを抽出して挿入したい依存関係があります。簡単です...

void Say_Something (const char *p_text)
{
  std::cout << p_text << std::endl;
}

それはオリジナルよりもどのように柔軟性がないのですか？さて、もし出力がユニコードであるべきだと決めたらどうなるでしょう。おそらくstd :: coutからstd :: wcoutに切り替えたいと思います。しかし、それは私の文字列がcharではなくwchar_tでなければならないことを意味します。すべての呼び出し元を変更する必要があるか、または（より合理的に）古い実装が文字列を変換して新しい実装を呼び出すアダプターに置き換えられます。

それは、私たちがオリジナルを維持していれば必要のない、その場でのメンテナンス作業です。

そして、それが取るに​​足りないと思われる場合は、Win32 APIからこの実際の関数を見てください...

http://msdn.microsoft.com/en-us/library/ms632680%28v=vs.85%29.aspx

これは、対処する12の「依存関係」です。たとえば、画面解像度が非常に大きくなる場合は、64ビットの座標値と、CreateWindowExの別のバージョンが必要になる可能性があります。そしてはい、古いバージョンがまだぶら下がっていて、おそらく裏側で新しいバージョンにマッピングされています...

http://msdn.microsoft.com/en-us/library/ms632679%28v=vs.85%29.aspx

これらの「依存関係」は、元の開発者にとって単なる問題ではありません。そのインターフェースを使用するすべての人は、依存関係の内容、指定方法、意味を調べ、アプリケーションに対して何をすべきかを考えなければなりません。これは、「賢明なデフォルト」という言葉が人生をより単純にすることができる場所です。

オブジェクト指向の依存性注入は、原則として同じです。クラスの作成はソースコードテキストと開発者時間の両方でオーバーヘッドであり、そのクラスが依存オブジェクトの仕様に従って依存関係を提供するように作成されている場合、依存オブジェクトは、必要がある場合でもそのインターフェイスをサポートするようにロックされます。そのオブジェクトの実装を置き換える。

これは、依存性注入が悪いと主張していると読むべきではありません。しかし、どんな良いテクニックでも、過度に間違った場所に適用される可能性があります。すべての文字列を抽出してパラメータに変換する必要があるわけではないのと同様に、すべての低レベルの動作を高レベルのオブジェクトから抽出して注入可能な依存関係に変換する必要があるわけではありません。

ここに私自身の最初の反応があります：基本的にパターンの同じ欠点。

• 学ぶには時間がかかる
• 誤解すると、善よりも害につながる可能性があります
• 極端に考えると、メリットを正当化するよりも多くの作業になる可能性があります

Inversion of Controlの最大の「欠点」（かなりDIではないが、十分に近い）は、アルゴリズムの概要を確認するための単一のポイントを削除する傾向があることです。ただし、これはコードを分離したときに基本的に何が起こるかです。1か所を見る機能は密結合の成果物です。

そのようなリストは存在しないと思いますが、それらの記事を読んでみてください。

• DIはコードを覆い隠す可能性があります（優れたIDEで作業していない場合）

• ボブおじさんによると、IoCを誤用すると、コードが不正になる可能性があります。

• 過剰なエンジニアリングと不要な汎用性の作成に注意する必要があります。

私は過去6か月間、Guice（Java DIフレームワーク）を広範囲に使用しています。全体的には（特にテストの観点から）素晴らしいと思いますが、欠点もあります。最も注目すべき点：

• コードは理解しにくくなる可能性があります。依存性注入は、非常に...創造的な...方法で使用できます。たとえば、カスタムアノテーションを使用して特定のIOStreams（例：@ Server1Stream、@ Server2Stream）を挿入するコードを見つけました。これは機能し、ある程度の優雅さがあることは認めますが、Guiceインジェクションを理解することがコードを理解するための前提条件になります。
• プロジェクトを学ぶときのより高い学習曲線。これはポイント1に関連しています。依存性注入を使用するプロジェクトの動作を理解するには、依存性注入パターンと特定のフレームワークの両方を理解する必要があります。現在の仕事を始めたとき、私はかなり多くの混乱した時間を費やして、Guiceが舞台裏で何をしていたのかを理解しました。
• コンストラクターが大きくなります。これは主にデフォルトのコンストラクターまたはファクトリーで解決できますが。
• エラーは難読化できます。最近の例では、2つのフラグ名が衝突しました。Guiceはエラーを静かに飲み込み、私のフラグの1つが初期化されませんでした。
• エラーはランタイムにプッシュされます。Guiceモジュールを誤って構成すると（循環参照、不適切なバインディングなど）、コンパイル時にほとんどのエラーが明らかになりません。代わりに、プログラムが実際に実行されるときにエラーが公開されます。

今私は不満を言った。私の現在のプロジェクトで、そしておそらく次のプロジェクトで、Guiceを（喜んで）使用し続けます。依存性注入は、優れた非常に強力なパターンです。しかし、それは間違いなく混乱を招く可能性があり、選択した依存関係注入フレームワークに呪いをかける時間をほぼ確実に費やします。

また、依存性注入が過度に使用される可能性があるという他のポスターにも同意します。

DIのないコードは、スパゲッティコードに巻き込まれるよく知られたリスクを冒します -一部の症状は、クラスとメソッドが大きすぎ、やりすぎて、簡単に変更、分解、リファクタリング、またはテストできないことです。

DIを多用するコードは、各小クラスが個別のラビオリナゲットのようなラビオリコードにすることができます。これは1つの小さなことを行い、単一責任の原則が守られているので、優れています。しかし、クラス自体を見ると、システム全体が何をしているのかを理解することは困難です。これは、これらの多くの小さな部品がどのように組み合わされているかによって異なり、わかりにくいからです。小さなものの大きな山のように見えます。

大きなクラス内の結合されたコードの大きなビットのスパゲッティ複雑さを回避することにより、単純な小さなクラスがたくさんあり、それらの間の相互作用が複雑である、別の種類の複雑さのリスクを負います。

これが致命的なマイナス面だとは思わない-DIはまだ非常に価値がある。たった1つのことを行う少人数クラスのある程度のラビオリスタイルは、おそらく良いでしょう。過剰でもスパゲッティコードとしては悪くないと思います。しかし、それがあまりにも遠くにある可能性があることを認識することは、それを回避する最初のステップです。それを回避する方法の議論のためのリンクをたどってください。

自社製のソリューションを使用している場合、依存関係はコンストラクターの目の前にあります。または、多分、見つけるのがそれほど難しくないメソッドパラメータとして。フレームワークは依存関係を管理しますが、極端な場合、魔法のように見え始める可能性があります。

ただし、あまりにも多くのクラスにあまりにも多くの依存関係があることは、クラス構造が台無しになっていることの明らかな兆候です。したがって、依存関係の注入（自社開発またはフレームワーク管理）は、そうでなければ暗闇に潜んでいる可能性のある、目立つデザインの問題を引き出すのに役立ちます。

2つ目のポイントをわかりやすく説明するために、ここではこの記事の抜粋（元のソース）を抜粋します。これは、コンピュータシステムだけでなく、システムを構築する上での根本的な問題であると心から信じています。

大学のキャンパスを設計するとします。設計の一部を学生や教授に委任する必要があります。そうしないと、物理学の建物は物理学者にはうまく機能しません。建築家は、人々が自分ですべてを行うために必要な物理学について十分に知っています。しかし、すべての部屋の設計をその居住者に委任することはできません。それは、瓦礫の巨大な山を得るからです。

全体的な設計の一貫性と調和を維持しながら、大規模な階層のすべてのレベルに設計の責任をどのように配分できますか？これは、アレクサンダーが解決しようとしている建築設計の問題ですが、コンピューターシステム開発の根本的な問題でもあります。

DIはこの問題を解決しますか？いいえ。しかし、すべての部屋を設計する責任をその居住者に委任しようとしているのかどうかを明確に理解するのに役立ちます。

私がDIに少し不満を感じる理由の1つは、すべての注入されたオブジェクトはインスタンス化するのに安価であり、副次的影響がないことです。

これが重要になるのは、依存関係が消費クラス内で頻繁に使用されない場合です。などのようなものIExceptionLogHandlerService。明らかに、このようなサービスは（うまくいけば:)）クラス内で呼び出されることはめったにありません。おそらく、ログに記録する必要のある例外に対してのみです。しかし、標準的なコンストラクター注入パターン ...

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

     ...
End Class

...このサービスの「ライブ」インスタンスを提供する必要があり、そこに到達するために必要なコスト/副作用を抑制しました。そうではないかもしれませんが、この依存関係インスタンスの構築にサービス/データベースのヒット、構成ファイルの検索、または破棄されるまでリソースのロックが含まれる場合はどうなるでしょうか。このサービスが必要に応じて構築された場合、サービスが配置された場合、または工場で生成された場合（すべてに問題がある）、必要な場合にのみ建設費がかかります。

さて、オブジェクトを構築することが安価で副作用を引き起こさないことが、一般に受け入れられているソフトウェア設計原則です。そしてそれはいい考えですが、いつもそうとは限りません。ただし、典型的なコンストラクター注入を使用すると、基本的にこれが当てはまることが要求されます。依存関係の実装を作成するときは、DIを考慮して設計する必要があります。おそらく、他の場所で利益を得るためにオブジェクト構築をより費用がかかるようにしたかもしれませんが、この実装が注入される場合は、おそらくその設計を再考することを強いられます。

ちなみに、特定の手法では、注入された依存関係の遅延読み込みを許可することで、この正確な問題を軽減できLazy<IService>ます。たとえば、依存関係としてクラスにインスタンスを提供します。これにより、依存オブジェクトのコンストラクターが変更され、オブジェクト構築費用などの実装の詳細がさらに認識されるようになります。これも間違いなく望ましくありません。

依存性注入を実際に分離することなく実装するだけでコードを分離したような錯覚。それがDIの最も危険なことだと思います。

これは、ちょっとしたテクニックです。しかし、依存性注入の欠点の1つは、開発ツールがコードを推論してナビゲートするのが少し難しくなることです。

具体的には、コード内のメソッド呼び出しでControl-Click / Command-Clickを実行すると、具体的な実装ではなく、インターフェイスのメソッド宣言に移動します。

これは、疎結合コード（インターフェースによって設計されたコード）のマイナス面であり、依存関係注入を使用しない場合（つまり、ファクトリーを使用する場合でも）に当てはまります。しかし、依存性注入の出現は、疎結合されたコードを大衆に本当に奨励するものなので、私はそれについて言及したいと思いました。

また、疎結合コードの利点はこれをはるかに上回ります。そのため、私はそれをnitpickと呼んでいます。私はこれが依存関係注入を導入しようとした場合に得られる可能性のあるプッシュバックの一種であることを知るのに十分な時間をかけて取り組んできましたが

実際、依存関係の注入で見つけられるすべての「マイナス面」について、それをはるかに上回る多くのプラス面が見つかると思います。

コンストラクターベースの依存性注入（魔法の「フレームワーク」を使用しない）は、OOコードを構造化するためのクリーンで有益な方法です。私が見た中で最高のコードベースで、Martin Fowlerの他の元同僚と何年もかけて、この方法で記述されたほとんどの優れたクラスが単一のクラスを持つことに気づき始めましたdoSomethingメソッド。

主な欠点は、関数型プログラミングの利点を得るために、クラスとしてクロージャを書くための手に負えない長手なOO方法であることに気づくと、OOコードを書く動機がすぐに消えてしまうことです。

コンストラクターインジェクションは大きな醜いコンストラクターにつながる可能性があることを発見しました（そして、コードベース全体でコンストラクターインジェクションを使用しています-おそらくオブジェクトが細かすぎますか？）。また、コンストラクターインジェクションを使用すると、恐ろしい循環依存関係が発生することがあります（これは非常にまれですが）。そのため、より複雑なシステムでは、いくつかのラウンドの依存関係インジェクションを伴う、ある種の準備状態のライフサイクルが必要になる場合があります。

ただし、オブジェクトが構築されると、単体テスト環境にあるのか、IOCコンテナーにロードされているのか、それがどのような状態にあるのか、間違いなくわかるので、セッターインジェクションよりもコンストラクターインジェクションを優先します。これは、回り道のような方法で、私が感じるのはセッター注入の主な欠点だと言っています。

（付記として、私はトピック全体が非常に「宗教的」であると思いますが、あなたのマイレージはあなたの開発チームの技術的熱狂のレベルによって異なります！）

IOCコンテナーなしでDIを使用している場合、最大の欠点は、コードに実際に依存している依存関係の数と、すべてが実際にどの程度密結合されているかをすばやく確認できることです。（「それでも良いデザインだと思いました！」）自然な進歩は、学習と実装に少し時間がかかる可能性があるIOCコンテナーに移動することです（WPFの学習曲線ほど悪くはありませんが、無料ではありません）どちらか）。最終的なマイナス面は、一部の開発者が善良さのユニットテストを正直に書き始め、それを理解するのに時間がかかることです。以前に何かを半日でクランクアウトできた開発者は、突然、すべての依存関係を模倣する方法を理解するために2日間を費やします。

Mark Seemannの答えと同様に、肝心なのは、コードのビットをまとめてハッキングして、ドア/プロダクションに放り投げるのではなく、より良い開発者になるために時間を費やすことです。あなたのビジネスはどちらを持っているでしょうか？あなただけがそれに答えることができます。

DIは手法またはパターンであり、フレームワークとは関係ありません。依存関係を手動で関連付けることができます。DIはSR（単一の責任）とSoC（懸念の分離）を支援します。DIはより良い設計につながります。私の見解と経験上、欠点はありません。他のパターンと同様に、誤解したり誤用したりする可能性があります（ただし、DIの場合は非常に困難です）。

フレームワークを使用してDIをレガシーアプリケーションに原則として導入する場合-できる最大の間違いは、それをService-Locaterとして誤用することです。DI + Framework自体は素晴らしく、私が見たすべての場所で物事が改善されました。組織の観点から見ると、すべての新しいプロセス、手法、パターンなどに共通の問題があります。

• あなたはあなたのチームを訓練しなければなりません
• アプリケーション（リスクを含む）を変更する必要がある

一般に、時間とお金を投資する必要があります。それ以外に、マイナス面はありません。

コードの可読性。依存関係はXMLファイルに隠されているため、コードフローを簡単に理解することはできません。

2つのこと：

• 構成が有効であることを確認するには、追加のツールサポートが必要です。

たとえば、IntelliJ（商用版）は、Spring構成の有効性のチェックをサポートしており、構成内の型違反などのエラーにフラグを立てます。そのようなツールのサポートがないと、テストを実行する前に構成が有効かどうかを確認できません。

これが（Scalaコミュニティで知られている）「ケーキ」パターンが良いアイデアである理由の1つです。コンポーネント間の配線はタイプチェッカーでチェックできます。アノテーションやXMLを使用しても、そのメリットはありません。

• プログラムのグローバルな静的分析が非常に困難になります。

SpringやGuiceのようなフレームワークでは、コンテナによって作成されたオブジェクトグラフがどのように見えるかを静的に決定することが困難になります。コンテナの起動時にオブジェクトグラフを作成しますが、/作成されるオブジェクトグラフを記述する便利なAPIは提供されません。

静的型付けを回避する手法を常に採用している場合、静的型付け言語の想定される利点は大幅に減少するようです。私がインタビューしたばかりの大きなJavaショップの1つは、ビルドの依存関係を静的コード分析でマッピングすることでした...効果的なものにするために、すべてのSpringファイルを解析する必要がありました。

IoCコンテナーは依存関係を適切な方法で解決する必要があるため、アプリの起動時間が長くなる可能性があります。