「バスタード注射」と「貧乏人の注射」の本当の違いは何ですか
「.Netでの依存性注入」の本から、オブジェクトグラフはアプリケーションの構成ルートで作成する必要があることを知っています。これは、IoCコンテナーを使用しているときに非常に理にかなっています。
DIを使用する試みが行われているときに私が見たすべてのアプリケーションでは、常に2つのコンストラクターがあります。1つはパラメーターとして依存関係を持つもので、もう1つはパラメーターなしで「デフォルト」のもので、もう1つは「更新」を呼び出すすべての依存関係をアップしますが、前述の本では、これは「バスタードインジェクションアンチパターン」と呼ばれ、これが私が「貧乏人のインジェクション」として知っていたものです。
これをすべて考慮すると、「Poor Man's Injection」はIoCコンテナを使用するのではなく、前述のComposition Rootにすべてのオブジェクトグラフを手動でコーディングすることになります。
だから私の質問は：
- これらの概念を正しく理解していますか、それとも完全に順調ではありませんか？
- IoCコンテナーですべての依存関係を登録する必要がある場合と、まったく同じコンポジションルートで手動でコーディングする場合とでは、IoCコンテナーを使用する本当のメリットは何ですか？
- 「Poor Man's Injection」が本当に何であるかを誤解している場合、誰かがそれを明確にしてもらえますか？
ありがとう
DIに関して言えば、相反する用語の使用がたくさんあります。用語Poor Man's DIも例外ではありません。ある人にとってそれは一つのことを意味し、他の人にとっては別のことを意味します。
この本でやりたかったことの1つは、DIに一貫したパターン言語を提供することでした。使用法が矛盾するこれらすべての用語については、2つの選択肢がありました。完全に新しい用語を考え出すか、最も一般的な使用法を選択します（私の主観的な判断による）。
一般に、私は完全に新しい（したがってエイリアン）パターン言語を作成するのではなく、既存の用語を再利用することを好みました。これは、特定のケース（Poor Man's DIなど）で、名前が本で定義されている定義とは異なる概念を持つ場合があることを意味します。これはパターンブックでよく起こります。
少なくとも私は、この本がプアーマンのDIとバスタード注射の両方を正確に説明しているように思われることを確信しています。
DIコンテナーの実際の利点については、この回答を参照します。 制御コンテナーの反転に対する引数
P.S。 2018-04-13：数年前にPoor Man's DIという用語が悪いことを認めるようになったことを指摘したいと思います（sic ！）原則の本質を伝える仕事なので、何年もの間、今では 代わりにそれを純粋なDIと呼んでいます です。
質問の2）についてのいくつかの注記。
IoCコンテナーですべての依存関係を登録する必要がある場合と、まったく同じコンポジションルートで手動でコーディングする場合とでは、IoCコンテナーを使用する本当のメリットは何ですか？
依存関係のツリーがある場合（他の依存関係に依存する依存関係に依存するクラスなど）：コンポジションルートですべての「ニュース」を実行することはできません。各クラスのコンストラクターなので、コードベースに沿って多くの「構成ルート」が広がっています
依存関係のツリーがあるかどうかに関係なく、IoCコンテナーを使用すると、コードを入力する手間が省けます。同じ
IDependencyに依存する20の異なるクラスがあると想像してください。コンテナーを使用する場合、IDependencyに使用するインスタンスを通知する構成を提供できます。これを1か所で作成すると、コンテナがすべての依存クラスでインスタンスを提供するようになりますコンテナーはオブジェクトの存続期間も制御できるため、別の利点があります。
これらすべて、DIによって提供される他の明らかな利点（テスト容易性、保守容易性、コード分離、拡張性...）
レガシーアプリケーションをリファクタリングし、依存関係を分離するとき、2つのステップのプロセスで行う方が簡単になる傾向があることがわかりました。このプロセスには、「貧乏人」と正式なIoCコンテナシステムの両方が含まれます。
まず、インターフェースをセットアップし、それらを実装するための「poor mans ioc」を確立します。
- これにより、正式なIoC設定のオーバーヘッド（および学習曲線）を追加することなく、依存関係が切り離されます。
- これにより、既存のレガシーコードへの干渉も減少します。デバッグする別の一連の問題を紹介するようなものはありません。
- 開発チームのメンバーは、同じレベルの専門知識や理解を決して持っていません。したがって、実装時間を大幅に節約できます。
- これにより、テストケースの足場も可能になります。
- これにより、後で正式なIoCコンテナシステムの標準も確立されます。
- これは、多くの人が時間をかけて段階的に実装できます。
次に、各IoCシステムには長所と短所があります。
- アプリケーション標準が確立されたので、IoCコンテナーシステムを選択する際に、知識に基づいた決定を行うことができます。
- IoCシステムの実装は、「貧しい人々」のコードを新しいIoCシステムと交換する作業になります。
- これは、時間の経過とともに、「貧しい人々」と並行して実装できます。これは一人でやった方がいいです。