4

オブジェクトを依存関係の作成に結び付けずに、Java オブジェクトの依存関係を取得する方法を少なくとも 3 つ見てきました。

依存性注入 - 一部のフレームワークは、外部構成に基づいて必要なオブジェクトを別のオブジェクトに注入します。例: Spring マネージド Bean

依存関係ルックアップ - クラスは、ある種のディレクトリ サービスで必要な依存関係をルックアップします。例: Java EE コンテナーでの JNDI ルックアップ

静的ファクトリ - グローバル スコープ内のオブジェクトは、オンデマンドでインスタンスを提供します。標準の Java SE API には、これらが散らばっているように見えます。

どちらが状況に最も適しているかについて、どのようなガイダンスを提供できますか?

4

3 に答える 3

6

オブジェクトは必要な参照を取得する方法を知る必要がないため、私は依存性注入を好みます。

依存関係ルックアップでは、オブジェクトがルックアップ サービスとその URL を認識している必要があります。

静的ファクトリはルックアップ サービスに似ています。

于 2010-08-18T19:04:38.043 に答える
2

私は依存性注入を好みます。

Spring Framework で DI について話すと、次のように表示されます

  1. IDE でサポートされています (エラー チェック、視覚化)。
  2. AOP、プロパティの読み込みなど、他の必要なものをセットアップできます...
  3. XML、注釈、JavaConfig など、さまざまな構成の可能性があります。
  4. デスクトップアプリケーションでも使用できます。

これらは、別のライブラリへの依存など、すべてのネガのバランスを崩します。別のアプローチを使用する必要があるのはなぜですか?

于 2010-08-18T19:23:39.230 に答える
1

これは実際にはコンテキストによって異なります。自己完結型のMathsAPIを作成している場合は、静的ファクトリを使用することをお勧めします。これは、コードの冗長性が低く、セットアップが不要で、おそらくより効率的であるためです。リモート依存関係にアクセス/提供する必要がある場合は、JNDI / LDAPルックアップ、またはESBメッセージングが適切に機能します。サービス/DAO/データソースを一般的なエンタープライズサーバーコードに注入するには、GoogleGuiceやSpringなどの一般的なDIフレームワークの1つを使用することをお勧めします。

ソフトウェア設計には、単一の「最良の」ソリューションはありません。それは常にトレードオフです。

于 2010-08-18T21:31:32.977 に答える