Poor Man's Dependency Injectionは、レガシーアプリケーションにテスト容易性を導入する良い方法ですか？

過去1年で、Dependency InjectionとIOCコンテナを使用して新しいシステムを作成しました。これは私にDIについて多くを教えてくれました！

ただし、概念と適切なパターンを学んだ後でも、コードを分離し、IOCコンテナーをレガシーアプリケーションに導入することは難しいと考えています。アプリケーションは、真の実装が圧倒されるほどの大きさです。値が理解され、時間が与えられたとしても。こんなことをする時間を与えられたのは誰ですか??

もちろん、単体テストをビジネスロジックに組み込むことが目標です！
テスト防止のデータベース呼び出しと絡み合っているビジネスロジック。

この記事を読みましたが、このLos Techiesの記事で説明されているように、Poor Man's Dependency Injectionの危険性を理解しています。私はそれが本当に何も切り離さないことを理解しています。
実装には新しい依存関係が必要になるため、システム全体で多くのリファクタリングが必要になることを理解しています。どんなサイズの新しいプロジェクトでも使用することは考えません。

質問： Poor ManのDIを使用して、レガシーアプリケーションにテスト容易性を導入し、ボールローリングを開始しても大丈夫ですか？

さらに、Poor ManのDIを真のDependency Injectionへの草の根アプローチとして使用することは、原則の必要性と利点を教育する価値のある方法ですか？

インターフェイスの背後でデータベース呼び出しの依存関係と抽象化を呼び出すメソッドをリファクタリングできますか？単純に抽象化することで、そのメソッドをテスト可能にします。これは、コンストラクターのオーバーロードを介してモック実装を渡すことができるためです。

今後、支援が得られると、プロジェクトを更新してIOCコンテナを実装し、抽象化を取り入れるコンストラクタを公開することができます。

NerdDinnerでのPoor Man's Injectionに対する批判は、クラスを正しくセットアップすることよりも、DIコンテナーを使用するかどうかとは関係がありません。

記事では、彼らはそれを述べています

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

は、最初のコンストラクターがクラスを構築するための便利なフォールバックメカニズムを提供する一方で、に対する緊密な依存関係も作成するため、間違っていますDinnerRepository。

もちろん、Los Techiesが示唆しているように、DIコンテナーを追加するのではなく、問題のあるコンストラクターを削除するのが正しい解決策です。

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

残りのクラスの依存関係が適切に反転されました。これらの依存関係を自由に挿入できます。

ここでは、「貧しい人のDI」が何であるかについて誤った仮定をします。

依然としてカップリングを作成する「ショートカット」コンストラクターを持つクラスを作成することは、貧乏人のDIではありません。

コンテナを使用せず、すべての注入とマッピングを手動で作成することは、貧乏人のDIです。

「貧乏人のDI」という言葉は、悪いことのように聞こえます。そのため、最近では「純粋なDI」という用語が推奨されています。これは、より肯定的に聞こえ、実際にはプロセスをより正確に説明しているためです。

貧乏人/純粋なDIを使用して既存のアプリにDIを導入するだけでなく、多くの新しいアプリケーションでDIを使用する有効な方法でもあります。そして、あなたが言うように、誰もが少なくとも1つのプロジェクトで純粋なDIを使用して、IoCコンテナーの「魔法」に対する責任を処理する前に、DIの仕組みを本当に理解する必要があります。

レガシーチーム/コードベースのParagidmシフトは非常に危険です。

レガシーコードの「改善」を 提案し、チームに「レガシー」プログラマーがいる場合は、「彼らはそれを間違っていた」と全員に伝え、会社の残りの時間は敵になります。

DIフレームワークをハンマーとして使用してすべての釘を打ち破ると、すべての場合でレガシーコードが良くなるよりも悪くなるだけです。個人的にも非常に危険です。

テストケースで使用できるように、非常に限られたケースでも、テストケースが@Ignore壊れたり、さらに悪いことに不満を言うと、せいぜいマークされたテストケースを「非標準」および「外部」コードにするだけです。管理に最も力を入れているレガシープログラマーは、「ユニットテストの無駄な時間」をすべてあなただけのせいにして「正しく」書き直されます。

DIフレームワーク、または「Pure DI」のコンセプトを基幹業務アプリに導入すると、管理者、チーム、特にリード開発者のスポンサーシップがなくても、巨大なレガシーコードベースがなくなります。チーム/会社で社会的および政治的にあなたのために。このようなことをすることは非常に危険であり、最悪の場合には政治的自殺になりかねません。

依存性注入は、問題を探すソリューションです。

定義によりコンストラクタを使用する言語は、何をしているのかを理解し、コンストラクタを適切に使用する方法を理解している場合、慣例により依存性注入を使用します。これはちょうど良い設計です。

依存性注入は、非常に狭い範囲の少量の場合にのみ有用です。

• 大きく変化するもの、または静的にバインドされた多くの代替実装があるもの。

  • JDBCドライバーは完璧な例です。
  • プラットフォームごとに異なるHTTPクライアント。
  • プラットフォームによって異なるロギングシステム。

• フレームワークの構成コードで定義でき、起動時に自動的に検出され、プログラムの実行中に動的にロード/リロードできる構成可能なプラグインを持つプラグインシステム。