重複の可能性：
DIフレームワークの必要性を理解する
私はいくつかの記事を読み、DIに関して何人かの専門家と話をしました。私が理解していないのは、DIの方法がオブジェクトを分離するという点です。次の記事でもシナリオについて説明していますが、SpringがPayrollApplicationのデカップリングにどのように役立つのかわかりません。デカップリングは、DIではなくポリモーフィズムで行われます。DIdefineltyは他の目的を果たします...
http://www.developer.com/java/dependency-injection-in-existing-java-code.html
ヒントと参考文献で十分です。ありがとう
具象クラスを直接インスタンス化していないため、依存性注入はオブジェクトを分離します。Springが自動的にインスタンス化します。DIを使用する代わりに、通常はインターフェイスへの参照を作成しますが、それでもオブジェクトを直接インスタンス化する必要があります。コードで参照されているconcreateクラスはまだあります。
編集：ファクトリパターンを使用してコードから実装を削除できることを忘れましたが、それは単にファクトリに移動するだけです。春は、すべての豆の巨大で一般的なファクトリーのようなものです。
デカップリングは、全か無かの概念ではありません。この記事では、ポリモーフィズムのみ (「設計 2」) を使用してオブジェクトをある程度分離していますが、PayrollApplication クラスは、PayrollApplication のコンパイル時に Employee の実装について認識している必要があります。
従業員の実装は PayrollApplication の依存関係であり、依存関係の注入を使用すると、より高いレベルの分離を実現できます。従業員インターフェイスのみを参照するように PayrollApplication をコンパイルし、従業員の実装 (おそらく別のチーム/組織によって作成されたもの) のみを提供できます。後で。
依存性注入に関するウィキペディアもチェックしてください。
依存関係注入パターンの主な目的は、コンパイル時ではなく、実行時に、または構成ファイルを介して、特定の依存関係インターフェイスの複数の実装から選択できるようにすることです。このパターンは、テスト時に複雑なコンポーネントのスタブ テスト実装を提供するのに特に役立ちますが、プラグイン コンポーネントの検索、またはソフトウェア サービスの検索と初期化によく使用されます。