1

ファクトリパターンを完全に理解するかどうかはよくわかりません。

Customer基本的に次のメソッドを持つクラスがあるとしましょう。

  • CreateCustomer-静的、顧客を最初から作成してデータベースに追加し、
  • LoadCustomerCustomer-静的、データベースからのインスタンスをロードし、
  • KillCustomer-静的ではなく、データベースから顧客を削除します。

よく理解できれば

  1. LoadCustomerファクトリクラスに入れるのに適した候補です。
  2. どうCreateCustomerですか？ファクトリクラスに入れることができると思います。そうですか？そうでない場合、静的CreateCustomerメソッドはデータベースの状態を変更してから、を呼び出します CustomerFactory.LoadCustomer。私見、これは悪い設計です。特定のオブジェクトは、自分のファクトリについて何も知る必要はありません。
  3. KillCustomerファクトリの非常に悪い候補のように思えます。ファクトリは、オブジェクトを作成するのではなく、すでに作成されたオブジェクトに作用します。一方で：
    • 非静的メソッドが顧客をデータベースから削除した場合でも、（KillCustomer呼び出された）オブジェクトは引き続き存在します。これは、オブジェクトがデータベースレベルで自殺し、ビジネスレベルで残っているのを見るのは非常に奇妙です。このレベルでは、工場からの電話KillCustomerの方が合理的です。たとえば、オブジェクトがアプリケーションにキャッシュされている場合、ファクトリはデータベースとキャッシュの両方からオブジェクトを削除する場合があります。
    • オブジェクトを作成するメソッドとオブジェクトを削除するメソッドを異なるクラスに入れるのも奇妙に思えます。なぜファクトリーは何かを構築するだけで、構築されたものを決して破壊できないのですか？

最後になりましたが、顧客がアプリケーションにキャッシュされているとしましょう。キャッシュの管理は誰が担当しますか？IMO、ファクトリはそれを実行する必要があります。オブジェクトを作成するため、データベースからプロパティが入力された新しいオブジェクトをロードする必要があるか、オブジェクトがすでにキャッシュに存在するかを選択することをお勧めします。

では、ファクトリパターンについて考えていることの何が正しく、何が間違っているのでしょうか。

4

1 に答える 1

3

工場はものを作るためのものではありません。何を構築しようとしているのか正確にわからない場合に、ものを構築するためのものです。私の意見では、あなたの方法はすべてファクトリーには適していません。

さて、根底にある継承階層にさまざまな種類の顧客がたくさんあり、Customer顧客を作成するために使用されるデータに関するいくつかの詳細が、どの種類の顧客が作成されたかを決定するCreateCustomer場合、ファクトリ メソッドの優れた候補になります。おそらく、LoadCustomerどの種類の顧客がデータベースに格納されているかを完全には把握していないためです。

しかしKillCustomer、まだ悪い候補です。それは、仮想メソッドであるべきだからです。次に、どのような種類の顧客が呼び出されたかを正確に認識します。

于 2010-09-04T09:24:59.583 に答える