依存性注入自体の利点を理解しています。たとえば、Springを例にとってみましょう。また、AOPやさまざまな種類のヘルパーなど、他のSpring機能の利点についても理解しています。次のようなXML構成の利点は何でしょうか。
<bean id="Mary" class="foo.bar.Female">
<property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
<property name="girlfriend" ref="Mary"/>
</bean>次のようなプレーンな古いJavaコードと比較して：
Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);これはデバッグがより簡単で、コンパイル時間をチェックし、Javaだけを知っている人なら誰でも理解できます。それでは、依存性注入フレームワークの主な目的は何ですか？（またはその利点を示すコードの一部）
更新：の
場合
IService myService;// ...
public void doSomething() {
myService.fetchData();
}IoCフレームワークは、複数ある場合に、注入するmyServiceの実装をどのように推測できますか？特定のインターフェイスの実装が1つしかなく、IoCコンテナーにそれを使用するように自動的に決定させると、2番目の実装が表示された後に壊れます。また、インターフェースの実装が意図的に1つしかない場合は、それを注入する必要はありません。
IoCのメリットを示す小さな構成を見るのは本当に興味深いでしょう。私はしばらくSpringを使用しており、そのような例を提供することはできません。また、休止状態、dwr、および私が使用するその他のフレームワークの利点を示す1行を表示できます。
更新2：
IoC構成は再コンパイルせずに変更できることを理解しています。本当にいいアイデアですか？再コンパイルせずにDB資格情報を変更したい場合は理解できます-彼は開発者ではない可能性があります。実際に、開発者以外の誰かがIoC構成を変更する頻度はどれくらいですか？開発者にとって、構成を変更する代わりにその特定のクラスを再コンパイルする努力はないと思います。そして、非開発者にとっては、おそらく彼の人生をより簡単にし、いくつかのより単純な設定ファイルを提供したいと思うでしょう。
更新3：
インターフェースとその具体的な実装間のマッピングの外部構成
それを外部のものにすることで何が良いのですか？すべてのコードを外部にする必要はありませんが、ClassName.java.txtファイルに配置して、オンザフライで手動で読み取り、コンパイルすることはできますが、再コンパイルは不要です。コンパイルを避けるべきなのはなぜですか？
手続き型コードではなく宣言的にマッピングを提供するため、コーディング時間を節約できます。
ときどき宣言的アプローチが時間を節約することを理解しています。たとえば、BeanプロパティとDB列の間のマッピングを一度だけ宣言し、HSQLに基づいてSQLをロード、保存、構築するときにhibernateがこのマッピングを使用します。これが宣言的なアプローチが機能する場所です。Spring（私の例では）の場合、宣言はより多くの行を持ち、対応するコードと同じ表現力を持っていました。そのような宣言がコードより短い場合の例があれば、私はそれを見たいです。
制御の原則の反転により、実際の実装を偽の実装に置き換えることができるため（SQLデータベースをメモリ内の実装に置き換えるなど）、ユニットテストが容易になります。
私は制御の利点の反転を理解しています（IoCはより一般的な-多くの種類の制御があり、そのうちの1つだけを反転しているため、ここで説明する設計パターンを依存性注入と呼びます-初期化の制御）。なぜ誰かがプログラミング言語以外のものを必要とするのかと尋ねていました。コードを使用して、実際の実装を偽の実装に確実に置き換えることができます。そして、このコードは構成と同じことを表現します-偽の値でフィールドを初期化するだけです。
mary = new FakeFemale();DIのメリットは理解しています。同じことを行うコードの構成と比較して、外部XML構成によってどのような利点が追加されるのか理解できません。コンパイルは避けるべきだとは思いません。毎日コンパイルしていますが、まだ生きています。DIの構成は宣言型アプローチの悪い例だと思います。宣言は、1回宣言され、さまざまな方法で何度も使用される場合に役立ちます。Hibernatecfgのように、BeanプロパティとDB列の間のマッピングは、保存、ロード、検索クエリの構築などに使用されます。SpringDI構成は簡単に次のように変換できます。この質問の最初のように、コードを構成することはできませんか？そして、それはBeanの初期化にのみ使用されますね。これは、宣言的アプローチがここで何も追加しないことを意味しますか？
hibernateマッピングを宣言するときは、hibernateにいくつかの情報を提供するだけで、それに基づいて機能します-何をすべきかは指示しません。春の場合、私の宣言は春に正確に何をするように指示します-なぜそれを宣言するのですか、なぜそれをしないのですか？
最終更新：
皆さん、多くの回答が依存関係の注入について教えてくれています。問題は、コードを初期化する代わりにDI構成の目的についてです。コードを初期化する方が短くて明確であると思う傾向があります。私の質問に対して私がこれまでに得た唯一の答えは、構成が変更されたときに再コンパイルを回避することです。これは私にとって大きな秘密なので、別の質問を投稿する必要があると思います。この場合、コンパイルを回避する必要があるのはなぜですか。