依存性注入自体の利点を理解しています。スプリングを例にとってみましょう。また、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();
}
IC フレームワークは、複数ある場合に注入したい myService の実装をどのように推測できますか? 特定のインターフェイスの実装が 1 つしかない場合、IoC コンテナーに自動的にそれを使用するように決定させると、2 番目の実装が表示された後に壊れます。また、インターフェイスの可能な実装が意図的に 1 つしかない場合は、それを注入する必要はありません。
その利点を示す IoC の構成の小さな部分を見ることは本当に興味深いでしょう。私はしばらくSpringを使用してきましたが、そのような例を提供することはできません. また、休止状態、dwr、および私が使用するその他のフレームワークの利点を示す 1 行を示すことができます。
更新 2:
再コンパイルせずに IoC 構成を変更できることを認識しています。それは本当に良い考えですか？誰かが再コンパイルせずに DB 資格情報を変更したいときは理解できます - 彼は開発者ではないかもしれません。実際に、開発者以外の誰かが IC 構成を変更する頻度はどれくらいですか? 開発者にとって、構成を変更する代わりにその特定のクラスを再コンパイルする努力はないと思います。また、開発者以外の場合は、おそらく彼の生活を楽にして、より単純な構成ファイルを提供したいと思うでしょう。
更新 3:
インターフェイスとその具体的な実装の間のマッピングの外部構成
それを外部化することの何がそんなに良いのですか？すべてのコードを外部にするわけではありませんが、ClassName.java.txt ファイルに配置し、その場で手動で読み取り、コンパイルすることはできますが、再コンパイルを回避できます。なぜコンパイルを避けるべきなのですか?!
手続き型コードではなく宣言的にマッピングを提供するため、コーディング時間を節約できます
宣言型アプローチが時間を節約する場合があることを理解しています。たとえば、Bean プロパティと DB 列の間のマッピングを 1 回だけ宣言すると、Hibernate はこのマッピングをロード、保存、HSQL に基づく SQL の構築などに使用します。ここで宣言的アプローチが機能します。Springの場合（私の例では）、宣言はより多くの行を持ち、対応するコードと同じ表現力を持っていました。そのような宣言がコードよりも短い例があれば、それを見てみたいです。
制御原理の反転により、実際の実装を偽の実装に置き換えることができるため (SQL データベースをインメモリのものに置き換えるなど)、単体テストが容易になります。
制御の反転の利点は理解しています (ここで説明する設計パターンを依存性注入と呼びたいと思います。なぜなら、IoC はより一般的だからです。多くの種類の制御があり、そのうちの 1 つ (初期化の制御) だけを反転しています)。なぜ誰かがプログラミング言語以外の何かを必要とするのかと尋ねていました。コードを使用して、実際の実装を偽の実装に置き換えることは間違いなくできます。そして、このコードは構成と同じことを表現します-フィールドを偽の値で初期化するだけです。
mary = new FakeFemale();
DIの利点は理解しています。同じことを行うコードを構成する場合と比較して、外部 XML 構成によって追加される利点がわかりません。私はコンパイルを避けるべきだとは思いません - 私は毎日コンパイルし、今も生きています。DI の構成は、宣言型アプローチの悪い例だと思います。宣言は、一度宣言され、さまざまな方法で何度も使用される場合に役立ちます。たとえば、hibernate cfg のように、Bean プロパティと DB 列の間のマッピングが保存、ロード、検索クエリの作成などに使用されます。Spring DI 構成は、次のように簡単に変換できます。この質問の冒頭のように、コードを構成することはできませんか? そして、それは Bean の初期化にのみ使用されますよね? つまり、宣言型アプローチでは何も追加されないということですよね?
休止状態のマッピングを宣言するとき、休止状態にいくつかの情報を与えるだけで、それに基づいて機能します-何をすべきかは教えません。春の場合、私の宣言は春に何をすべきかを正確に伝えます-では、なぜそれを宣言し、なぜそれをしないのですか?
最終更新:
みんな、多くの回答が依存性注入について教えてくれています。私はそれが良いことを知っています。質問は、コードを初期化するのではなく、DI 構成の目的に関するものです。コードを初期化する方が短くてわかりやすいと思う傾向があります。私の質問に対するこれまでの唯一の答えは、構成が変更されたときに再コンパイルを回避することです。別の質問を投稿する必要があると思います。これは私にとって大きな秘密であるためです。この場合、コンパイルを避ける必要があるのはなぜですか。