Java EEでCDIを使用する方法を説明する記事がたくさんあることは知っていますが、これが実際にどのような利点をもたらすのか理解するのに苦労しています。たとえば、現在Fooのインスタンスを使用しているクラスがあるとします。私はどちらかをするかもしれません
Foo myFoo = new Foo();
また
// Better, FooFactory might return a mock object for testing
Foo myFoo = FooFactory.getFoo();
私はCDIでそれを読み続けています：
@Inject
Foo myFoo;
しかし、なぜこれが以前のファクトリベースのアプローチよりも優れているのでしょうか？私が気付いていない他のユースケースがあると思いますが、これを特定することはできませんでした。
以下の応答を理解した場合、概念は、DIフレームワークが一元的に構成されたマスターオブジェクトファクトリとして機能するということです。これは合理的な解釈ですか？
アップデート
それ以来、私はSpringを学び始めましたが、これは今ではもっと理にかなっています。以下の段落は、Spring in PracticeAccountServiceから抜粋したもので、。のインスタンスを使用するクラスの例を取り上げていますAccountDao。長い引用をお詫びしますが、注入されたリソースが標準の初期化よりも何かを提供する理由の核心にあると思います。
newキーワードを使用してAccountServiceを構築することもできますが、サービスレイヤーオブジェクトの作成がそれほど簡単になることはめったにありません。多くの場合、DAO、メール送信者、SOAPプロキシなどに依存します。AccountServiceコンストラクターで（または静的初期化を介して）これらの各依存関係をプログラムでインスタンス化できますが、それらがスワップアウトされると、ハードな依存関係とカスケード変更が発生します。
さらに、依存関係を外部で作成し、setterメソッドまたはコンストラクター引数を介してAccountServiceに設定できます。そうすることで、ハードな内部依存関係が排除されます（AccountServiceでインターフェースによって宣言されている限り）が、初期化コードはどこにでも複製されます。DAOを作成し、それをAccountServiceにSpringの方法で接続する方法は次のとおりです。
<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>
<bean id="accountService"
class="com.springinpractice.ch01.service.AccountService">
<property name="accountDao" ref="accountDao"/>
</bean>
上記のようにBeanを構成すると、プログラムはAccountServiceSpring ApplicationContextからのインスタンスを要求できるようになり、SpringDIフレームワークはインスタンス化が必要なすべてのものをインスタンス化した後の処理を行います。