私たちのアプリケーションは、オブジェクトを吐き出すためにファクトリを多用していますが、ファクトリが常に本当に必要なのか疑問に思うことがよくあります。また、「既知のオブジェクト」のインスタンスを Bean として作成する方が良いというわけではありません。引数は、開発者がこれらの返されたオブジェクト (インターフェイスの型で返される) の実装をカスタマイズしていることが多く、取得しているものを技術的に正確に「認識」していないため、ファクトリを使用することをお勧めします。インターフェース、クラスの実装、そしてファクトリーを必要とするファクトリーを作成する必要があるところです。ただし、オブジェクトは変更されません。実際には、特定の目的を持つ具体的なオブジェクトです...状態を取得および設定する Bean をインスタンス化するだけでよいのでしょうか? 私は時期尚早の一般化を避けようとしています。
2 に答える
3
ファクトリまたは依存性注入ソリューションの全体的な目的は、クライアントとオブジェクトのランタイム タイプの間の結合を減らすことです。クライアントがインターフェイスとデータのソースを認識している必要があるのは事実ですが、ソースはインターフェイスを実装する任意の型を自由に返すことができます。また、ランタイム タイプの知識を 1 か所にカプセル化することもできます - ファクトリまたは依存性注入ソリューションだけが知る必要があります。
これは、ランタイム プロキシを生成して宣言型トランザクションを実装する場合に役立ちます。クライアントの観点から見ると、彼らはインターフェースを扱っています。ファクトリは、クライアントのトランザクションを管理するプロキシを生成できます。
「new」と入力すると、クライアントは実行時にコンパイル タイプを使用するように関連付けられます。それを変えることは、クライアントを変えることを意味します。コード内で「新規」と呼ぶ場所がたくさんある場合、メンテナンスの問題になる可能性があります。
「新規」と呼ぶのはいつですか？メソッド内で、スコープ外になったときに GC されるローカル オブジェクトをインスタンス化するのが適切だと思います。メソッドはそれらを作成し、使用して、完了します。そこでは工場や DI ソリューションを使用しません。
工場を閉鎖し、Spring、Guice、PicoContainer などの依存性注入ソリューションを検討する必要があるかもしれません。
于 2009-09-26T14:41:24.043 に答える
2
ファクトリ メソッドを持つということは、オブジェクトにパブリックな既定のコンストラクターがないことを意味しますが、常に意味するわけではありません。ファクトリ メソッド (たとえば) がある場合、それをバイパスして直接作成することはできないという考えです。
最も単純なケースでは、新しいオブジェクトを返す public static メソッドではなく public コンストラクターを使用する理由はほとんどなく、オブジェクトにはプライベート/保護されたコンストラクターしかありません。
そうは言っても、パブリックのデフォルト コンストラクターが必要な場合や、それがないと非常に不便な場合があります。例には、Spring の BeanWrapper の使用が含まれます。一部のメソッドには、既定のコンストラクターが必要です。JavaBeans インターフェースを使用するには、それが必要です。リフレクションは、それがないと扱いにくい場合があります (これが前の 2 つの理由の一部です)。
このような場合、ファクトリがインターフェイスを返し、そのクラスがインターフェイスを実装しない限り、ファクトリを持つことはおそらくほとんど価値がありません。繰り返しになりますが、ほとんどの (すべてではないにしても) 戻り値の型 (およびパラメーターの型) はクラスではなくインターフェイスである必要がありますが、それはまったく別の引数です。
ファクトリを持つことのもう 1 つの潜在的な欠点は、ファクトリが何らかの形式の外部状態に依存したり変更したりする厄介な傾向を持つ可能性があるという点で、テスト容易性が低下する可能性があることです。これは必ずしもそうではありませんが、たとえば次のコードです。
Calendar cal = Calendar.getInstance();
対
Calendar cal = new GregorianCalendar();
ローカリゼーション/国際化に基づいて、異なる結果が得られます。
于 2009-09-26T15:05:04.537 に答える