4

したがって、これが合法的な工場であるかどうかはわかりません。私が目にするほとんどの工場では、クライアントに次のようなものがあります。

if(//something)
    factory = new Type1Factory();
else
    factory = new RegularFactory();

そして、次のようにしてオブジェクトを作成しますfactory.Create();

したがって、基本的に、必要なファクトリを確認する条件は、呼び出しコードにあります。私はそれを隠して、工場自体に状態を持たせたいと思いますが、それはもはや工場とは呼ばれないのでしょうか?

このようなもの：

DateScheduleRequest request = new DateScheduleRequest();
DateScheduleBuilder dateScheduleBuilder = new DateScheduleBuilderFactory(request).Create();

dateScheduleBuilderオブジェクトは基本的に、ファクトリ コンストラクタに送信されたリクエストに応じて特定のタイプになります。

これには別のパターンがありますか、それとも工場を行うための特定の方法ですか?

基本的にDateScheduleBuilderは、他のタイプのビルダーが継承する親クラスになりますが、私の呼び出しコードは、この抽象クラスが 1 つのメソッドを持っていることを認識しており、リクエスト タイプを認識する必要はありません。それをファクトリに渡し、1 つのメソッドを呼び出す必要があります。

4

4 に答える 4

3

2番目の部分でファクトリーパターンを説明していると思います。最初の部分は、呼び出し元が目的のオブジェクトを構築する方法を知っていることに依存しているため、そうではありません。あなたの例では、オブジェクト内の情報を解釈し、から派生したオブジェクトを返すDateScheduleBuilderFactory方法を知ることができます。requestDateScheduleBuilder

要するに、Johm Domが上で言ったように. あなたはすでにそこにいます...

于 2012-05-02T14:29:30.733 に答える
1

まず、最初のスニペットはまったく問題ありません。これをリファクタリングするよりも、機能を追加してバグを修正することに時間を費やしたいと思います。

このコードを最初から設計していた場合、ifeg をコンストラクターで非表示にします。経験則として、「ライブラリが消費者のために何かを簡単にできるときはいつでも、ライブラリはそれを行うべきです」。

3 番目のオプションは、if ステートメントを vtable - ポリモーフィズムに移動することです。

于 2012-05-02T14:33:56.683 に答える
1

持っているものでOKです。

代替案は、工場工場を持つことです。したがって、リクエストに基づいてファクトリの実装を取得するメソッドを持つクラスがあります（IDateScheduleBuilderFactory GetDateSceduleBuilderFactory(request)その後、コンシューマーが呼び出しCreate()てIDateScheduleBuilderFactoryビルダーオブジェクトを取得するようなものです。

少し複雑ですが、単一の責任を持つ単一のクラスがあることを意味します (つまり、要求を正しいタイプのファクトリに変換するクラスと、実際のさまざまなタイプのファクトリになる他のクラス)。これをより簡単にテストします。特定の要求が与えられたときに、正しいタイプのファクトリが使用されていることをどのようにテストしますか? メソッドによって返される型をチェックするだけでなく、create の結果によってこれを判断する必要があります GetDateSceduleBuilderFactory()。

また、現在のファクトリにメソッドを公開させて、public bool CanHandleRequest(request)各ファクトリが特定のリクエストに対して正しいファクトリであるかどうかを判断できるようにすることもできます。その後、ファクトリ ファクトリはコンストラクタでファクトリのコレクションを受け入れることがGetDateSceduleBuilderFactory(request)でき、メソッドが呼び出されたときにそれが可能になります。すべてのファクトリをループして、リクエストを処理できるかどうかを各ファクトリに尋ね、処理できるファクトリが見つかるとそれを返します。

これには、新しいファクトリを追加するときにロジックを変更する必要がないという利点があります。リフレクションによってインターフェイスを実装するすべてのファクトリを取得し、新しいファクトリを追加すると自動的に選択されるコードをいくつか持つことができます。上。

于 2012-05-02T14:45:15.973 に答える
0

厳密に言えば、どのオブジェクトを作成するかを決定するために型を使用しないため、これはファクトリではありませんが、Head First Design Patterns の本では単純なファクトリと呼ばれているほど一般的な (そして便利な) イディオムです。

私の見解では完全に正当であり、適切な場所で非常に役立ちます (たとえば、戦略を作成する場合)。

于 2012-05-02T14:50:43.033 に答える