dependency-injection - (ほぼ) 各クラスに DI コンテナーを注入するアンチパターンはありますか?

Question

最近は、クラスの依存関係を定義してコンストラクターで渡すことをあまり気にしていないことに気付きましたが、常に DI コンテナーを渡し、それをプライベート属性に保持しています。この方法では、クラスの依存関係が明確に定義されていないため、必要なときにコンテナーからすべてを取得します。

どういうわけか、このソリューションについては悪い印象を持っていますが (コンテナーへのアクセスによるオーバーヘッドは別として)、あまりにも多くの欠点を考えることはできません。依存関係の定義が緩いと、クラスの移植性が低下する可能性があるか、リファクタリング時に驚きが生じる可能性があります...?

これについてあなたはどう思いますか？

score 11 · Accepted Answer

絶対に間違っています。オブジェクトに DI コンテナーを配置しないでください。注射されていることを知る必要も気にする必要もありません。これは、「電話しないでください。電話します」とは一致しません。

これは逆です。アプリ全体が DI エンジンを認識していますが、そこから必要な Bean を取得します。

注釈によって関係が多少変わると主張する人もいると思いますが、これは、Beanが相互に接続されているという事実について何かを知っているからです。しかし、構成が XML に外部化されたとき、Bean が DI を知らないのは事実でした。

score 3 · Accepted Answer

これはアンチパターンであり、コードのテストをまだ書いていないことは間違いありませんが、これは本当に悪いことです。

テストを書き始めると、テスト不可能なコードを書いていることがわかります。

Service Locator アンチパターンの使用
あなたはデメテルの法則に違反しています
単一責任の原則に従っていない
オブジェクトの実際の依存関係を隠しています (Dependency-Injection パターンを使用していません)
どのアプリケーションでも、オブジェクトの 2 つの大きな山の間に実際の分離はありません。
- ビジネスオブジェクト: 責任はビジネスロジック、ドメインの抽象化
- オブジェクトの配線と構築: 責任はオブジェクトグラフを構築することです。

コンポーネントの単体テストを書きたい日には、この決定を後悔し、コードをリファクタリングするか、単純な単体テスト (テストコンテナーを作成し、このコンテナーにモックを挿入する) の代わりに統合テストを作成する必要があります。

私のアドバイスは、このガイドを読んでテスト可能なコードを書くことです: (これは、Google で一生懸命働いている人が使用するガイドです)

必要に応じて、Misko Hevery によるテストの心理学ときれいなコードについての次のビデオから始めてください。

2 に答える 2