問題タブ [factory-pattern]

いくつかのクラスのコードを節約するために、抽象クラスに取り組んでいました。これらのクラスはすべて、さまざまな静的呼び出しを通じて自身をインスタンス化するファクトリです。これらすべてのメソッドを抽象クラスに入れることで、いくつかのコードを節約できました。

しかし、遅い静的バインディングの問題に遭遇しました... 私たちの Web ホストは 5.3 以降を使用していないため、get_called_class にアクセスできません。私が持っている場合

抽象クラスで__CLASS__は、呼び出されたクラスを実際に使用したい場合の抽象クラスの名前です。

子クラスが独自のインスタンス化メソッドを持ち、抽象化された親に依存していない Web 上の抽象ファクトリの例を見てきました。ただし、この場合、抽象クラスを使用する唯一の理由はコードを保存することなので、そこでそれができなければ、その価値は大幅に低下します。

PHP < 5.3 で回避策はありますか? debug_backtrace()?

編集：

私はテストを行いましたが、うまくいかdebug_backtrace()ないようです！これがlate static bindingが必要な理由だと思います。

そして結果：

現在、Python で Factory デザイン パターンを実装していますが、いくつか質問があります。

1. 実際の具象クラスの直接インスタンス化を防ぐ方法はありますか? たとえば、Vehicles を生成する VehicleFactory がある場合、ユーザーはそのファクトリを使用するだけで済み、誰かが誤って Car() または Truck() を直接インスタンス化するのを防ぐことができます。おそらくinit ()で例外をスローできますが、それはファクトリがそのインスタンスを作成できないことも意味します...

2. 工場が中毒性を増しているように思えます。内部実装を変更してもクライアント コードが変更されないように、すべてがファクトリになる必要があるようです。実際にファクトリを使用する必要があるのはいつで、いつ使用するのが適切でないのか知りたいです。たとえば、私は Window クラスを持っているかもしれませんが、現在このタイプは 1 つしかありません (PlasticWindow、ReinforcedWindow などはありません)。その場合、将来さらに多くの種類の Windows を追加する可能性がある場合に備えて、クライアントにファクトリを使用して Window を生成する必要がありますか?

3. 工場を呼び出す通常の方法があるかどうか疑問に思っています。たとえば、Vehicle ファクトリを Vehicles と呼んでいるので、コードは Vehicles.create(...) のようになります。VehicleFactory のように多くのチュートリアルが実行されているのを目にしますが、長すぎて、実装も公開されているように感じます。

編集:「実装を公開する」とは、それが工場であることを人々に知らせることです。私が感じたのは、クライアントはそれがファクトリであることを知る必要はなく、オブジェクトを返すことができる何らかのクラスとして知る必要があるということでした (これはもちろんファクトリですが、クライアントに明示的に伝える必要はないのでしょうか?)。ソースコードが簡単に公開されることは知っているので、「ソースコードで機能が実装されている方法を公開する」という意味ではありませんでした。

ありがとう！

複雑な静的ファクトリ メソッドを持つクラスがあり、それを ClassA と呼びましょう。ClassA を ClassB に拡張しました。ClassB のファクトリ メソッドで ClassA のファクトリ メソッドが行うすべてのことを行います (ClassB を返すことを除く)。

これは反響するはずですClassB

ClassA の Factory Method を ClassB にコピー アンド ペーストせずに使用する方法はありますか? PHP5 を使用していますが、5.3.0 は使用していません。

作成しようとしているDTOマッパーにファクトリパターンを実装する方法を理解するのに苦労しています。私は自分のデザインを再考する必要があると確信しています。これが私が実行しているものの非常に小さな例です：

と工場を使用するには：

パイロット番号をパイロットに型キャストせずにロードする方法を教えてください。これはこれを行うための間違った方法ですか？パイロット番号をPersonクラスに入れることはできますが、その場合、Employeeは番号を継承するため、それは私が望んでいることではありません。私に何ができる？

ありがとう！

-ジャクソン

C# でオブジェクト ファクトリを作成したいと考えています。このオブジェクト ファクトリを介してのみオブジェクトを作成したいのですが、これを実現するにはどうすればよいですか? オブジェクトを作成および初期化するパブリック メソッドを持つサティック クラスのような単純なオブジェクト ファクトリを作成する方法を知っています。しかし、人々がオブジェクト ファクトリを介してのみオブジェクト インスタンスを作成できるようにする必要があります。何かアイデアはありますか?

PS私はリフレクションを巻き込むのは好きではありません。単純なOOPアプローチを使用してください。

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

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

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

よく理解できれば

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

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

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

ジェネリック メソッド内で内部コンストラクターを使用してオブジェクトを構築することは可能ですか?

FooFactoryは と同じアセンブリにありFooます。クラスは、次のようにファクトリ メソッドを呼び出します。

コンパイル時エラーが発生します。

'Foo' は、ジェネリック型またはメソッド 'FooFactory.CreateFoo()' でパラメーター 'TFooType' として使用するために、パブリック パラメーターなしのコンストラクターを持つ非抽象型である必要があります

これを回避する方法はありますか？

私も試しました：

これにより、実行時に同じエラーが発生します。

コードが自動生成され、コードを変更したくない場合 (たとえば、基本クラスを追加するため)、Web サービスをファクトリ パターンで使用できますか?

これを行う理由は、同一の 2 つの Web サービスがあり、1 つはテスト データ用で、もう 1 つはライブ データ用であり、コードが実行されている環境に基づいてサービスを切り替えたい場合です。

【追記】
C#3を使っています。

この例を考えてみましょう

インターフェイス

相続人

ファクトリークラス

使用例:

私の質問は、 特別なシナリオで使用するだけなので、ALgorithm1 クラスに別のメソッドを追加するが、インターフェイスには追加しないということです。

このようなUIでそれをどのように呼び出すと思いますか

他の解決策はありますか？前もって感謝します

編集：現在のプロジェクトデザインに似るように書き直しました

現実世界のシナリオをシミュレートするために使用される C++ アプリケーションを開発しています。このシミュレーションに基づいて、私たちのチームは、このような現実世界のシナリオで機能するさまざまなアルゴリズムを開発、テスト、評価します。

いくつかのシナリオを定義する可能性 (いくつかのパラメーターが異なる可能性がありますが、将来のシナリオでは新しいクラスのオブジェクトを作成する必要があるかもしれません) と、アルゴリズムのセットを維持する可能性 (これもパラメーターのセットですが、また、作成するクラスの定義)。パラメータはコンストラクタでクラスに渡されます。

すべてのシナリオとアルゴリズムの構成を管理するには、どの方法が最適なのか疑問に思っています。ある開発者が「彼の」アルゴリズムを使用してあるシナリオに取り組み、別の開発者が「彼の」異なるアルゴリズムを使用して別のシナリオに取り組むことは容易に可能です。それでも、パラメータ セットは巨大である可能性があり、「共有可能」である必要があります (シナリオ A で特定のアルゴリズムのパラメータ セットを定義した場合、コピー & ペーストなしでシナリオ B のアルゴリズムを使用できるはずです)。

私のタスクを達成するには、主に2つの方法があるようです。

• 私の要件を処理できる構成ファイル形式を定義します。この形式は、XML ベースまたはカスタムの場合があります。C++ には C# のようなリフレクションがないため、新しいアルゴリズム クラスがプロジェクトに追加されるたびに構成ファイル パーサーを更新する必要があるようです ("MyClass" のような文字列を MyClass の新しいインスタンスに変換するため)。 ）。すべてのセットアップの名前を作成し、この名前をコマンド ライン引数として渡すことができます。

  • 長所は次のとおりです。パラメータを変更して再実行するためのコンパイルは不要です。シミュレーション結果とともに構成ファイル全体を簡単に保存できます。
  • contra: 与えられたテンプレート引数でインスタンス化する必要がある多くのテンプレート クラスを使用しているため、特に大変です。ファイルを書き込むためのIDEサポートはありません（少なくとも、パラメーター/クラスが追加されるたびに更新する必要があるXSD全体を作成する必要はありません）

• すべてを C++ コードで接続します。さまざまな作成ロジックをすべて分離するためにこれを行う方法は完全にはわかりませんが、シナリオ間でパラメーターを再利用できます。また、すべてのセットアップに（文字列）名前を付け、この名前を使用してコマンドライン引数からセットアップを選択しようと思います。

  • 長所: タイプ セーフ、IDE サポート、パーサー不要
  • 短所: 設定を結果とともに簡単に保存するにはどうすればよいですか (シリアライゼーションの可能性もありますか?)?、パラメータを変更するたびにコンパイルが必要です

ここに私の質問があります: - あなたの意見は? 重要な長所/短所を見逃していませんか? - 3 番目のオプションを見逃しましたか? - 十分な柔軟性を提供する構成ファイル アプローチを実装する簡単な方法はありますか? - セカンド アプローチですべてのファクトリ コードをどのように整理しますか? このようなものに適した C++ の例はありますか?

どうもありがとう！