8

私はEffective Javaを読んでいて、TDDと依存性注入に関連して、最初の項目「コンストラクターの代わりに静的ファクトリメソッドを使用する」に関していくつかの懸念があります。

この項目には、public/protected/default コンストラクターを持たないようにし、静的ファクトリーを使用して公開する必要があると書かれています。ファクトリに名前を付けることができる、サブタイプを返すことができる、冗長性を減らすことができるなど、静的ファクトリを使用することに関連するすべての利点に同意します。それを使用してクラスをモックすることはできません。静的ファクトリを持つクラスをモックすることはできません。そのため、テスト駆動開発の妨げになります。

2 番目の点として、彼は、今日のエンタープライズ開発ではほとんどのアプリケーションが何らかの依存性注入コンテナーを使用していることを見逃していたと思います。ですから、DI を使用して依存関係を注入できるのに、なぜそれを使用する必要があるのでしょうか。

DI と TDD を含む今日の Java エンタープライズ開発にどのように適用されるか説明してください。

4

3 に答える 3

6

DI エンジンは工場です。

Joshua Bloch は DI を十分に理解しています。DI の台頭は "Effective Java" の初版の後に行われたため、これは歴史の産物だと思います。

「Effective Java」は2001年に出版されました。 Martin Fowlerは 2004 年にこの用語を作り出しました。Spring の 1.0 リリースは 2004 年 3 月に行われました。

Joshua Bloch は、第 2 版のその章を変更しませんでした。

ポイントは「new」が導入するカップリング。それを理解している人なら誰でも、工場は簡単にDIエンジンに飛躍できます。重要なのは、「新しい」こと、および工場を使用することによる救済策に関する彼の発言は、依然として真実であるということです。

于 2010-06-25T11:23:57.147 に答える
4

ここに 2 つの個別の問題があります。

  • 静的ファクトリと new() の使用
  • 依存性注入

new を使用する場合、コードは静的メソッドを使用するのと同じくらい密結合されています。実際には、静的ファクトリが何らかの魔法を実行して、インターフェイスのサブクラスまたは実装である限り、特定の実装を返すことができるため、さらに悪化します。

依存性注入の原則は、ハリウッド原則とも呼ばれます。「私たちに電話しないでください。電話します」。したがって、その哲学では、コード内で new() または静的ファクトリを呼び出すべきではありませんが、DI フレームワークまたは単体テストのいずれかの外部のものにそれを実行させる必要があります。これは、他の場所で行われるため、工場や new の使用とは関係ありません。

その場合、テスト ファクトリを自分の管理下に注入できるため、ファクトリの方が適しています。new では、これは不可能です (テスト クラスパスでダミー オブジェクトを使用して実装を非表示にするなど、クラスパスに奇妙なことをしない限り、これはお勧めしません)。

于 2010-06-25T11:16:26.440 に答える