問題タブ [factory-pattern]

オブジェクト内でファクトリ クラスの代わりにファクトリ メソッドを使用することをお勧めするのはどのような場合ですか?

依存性注入の使用法として引用されている例のほとんどは、ファクトリ パターンを使用して解決することもできます。使用法/設計に関しては、依存性注入と工場の違いがぼやけているか薄いようです。

誰かが私に、それをどのように使用するかが違いを生むと言ったことがあります！

私は以前、 StructureMapを DI コンテナーとして使用して問題を解決しましたが、後で単純なファクトリで動作するように再設計し、StructureMap への参照を削除しました。

それらの違いと、どこで何を使用するか、ここでのベストプラクティスは何ですか?

ファクトリーパターンと戦略パターンの違いを説明できる人はいますか?

私にとって、両方とも追加のファクトリークラス（ファクトリーパターンで製品のオブジェクトを作成する）以外は同じように見えます

Builder デザイン パターンと Factory デザイン パターンの違いは何ですか?

どちらがより有利で、その理由は?

これらのパターンをテストして比較/対比したい場合、調査結果をグラフとして表すにはどうすればよいですか?

しばらくの間、ファクトリ メソッド作成パターンを使用しています。私はつい最近、次のように言われました。

理由を教えたり、解釈を与えたりせずに、私の「テック」リードによるファクトリメソッド作成パターンではありません。私は親切に説明を求めましたが、彼女は時間がないと言いました。改名するように言われました。私が間違っていれば、何年にもわたってこれを間違って実装してきたことを間違いなく受け入れるでしょう。これは、ファクトリ メソッド作成パターンを実装する方法ですか? 前もって感謝します。

Factory パターンを使用していると思われる Java コードを扱っていましたが、そのパターンに完全には納得していません。

私のコードはこれを行います：

そして、コードのどこかに：

私が考えているポイントは、ファクトリ クラスに静的な create() メソッドがない場合、ファクトリをインスタンス化する必要があるということです。この IMO は、オブジェクト自体をインスタンス化するのと同じくらい複雑でなければなりません。

そのようなファクトリが生成されるオブジェクトのコレクションを返すことができるという議論は十分ではないと思います。ファクトリから実際にオブジェクトを作成する前にファクトリ インスタンスを作成する必要がある場合は、よりクリーンな回避策があると思います。

createメソッドはファクトリクラスのstaticメソッドの方がいい気がします。しかし、私の意見が完全に「正しい」わけではないことも確信しています。

SO コミュニティは、ファクトリ オブジェクトをインスタンス化する方が静的な作成メソッドを使用するよりも優れている例を示すことができますか?

また、これらのリンクと回答をリストした同様の質問への回答に出くわしました。そのため、FactoryMethodPattern、FactoryMethod、およびCreationMethodの違いをコード例で明確に知る必要があります。

タイトルが示すように、「ああ！ここでファクトリパターンを使用する必要があります！」という意味の頭のトリガーをいつオフにする必要がありますか？これらの瞬間は他の多くのデザインパターンで発生することがわかりますが、私は自分自身を止めてこのパターンについて考えることは決してありません。

私はこの質問を書き直すと思いました（同じ繰り返し）。オリジナルは、EAV/CRデータベースの周りにリポジトリパターンをラップする方法でした。私は別のアプローチを試みています。

質問：「ファクトリ」デザインパターンの方法でデータリポジトリをどのようにコーディングできますか？ エンティティの数は固定されていますが、これらのエンティティの属性はかなり顧客固有です。彼らはすべて類似した製品を宣伝していますが、各顧客はビジネスモデルに基づいて異なる情報を提供しています。たとえば、廃棄物のスラブの割合を気にする人もいれば、販売されたポンドの量を気にする人もいます。別の顧客を見つけるたびに、一連のフィールドを追加し、一連のフィールドを削除してから、各ソリューションを最新の一般的なリリースに最新の状態に保つために何時間も費やします。

リポジトリクラスをファクトリパターンに配置できると思ったので、顧客のタイプがわかれば、どのフィールドを使用するかがわかります。実用的？もっといい方法？Webフォームは、レイアウト上のフィールドを反映するように変更されたユーザーコントロールを使用します。現在、レイアウトで見つかったフィールドを製品テーブルで見つかったフィールドに「結合」してから、CRUD共通フィールドを結合しています。

前の質問の内容：

同じエンティティに対して異なるクラスを許可するEAV/CRデータモデルがあります。これは、顧客が大きく異なる製品を持っている製品を追跡します。顧客は、製品の「クラス」を定義し、フィールドをロードしてから、データを入力できます。例えば、

Product.Text_Fields.Name
Product.Text_Fields.VitaminEContent

これにリポジトリパターンをラップする方法について何か提案はありますか？

3つのテーブルEAVがあります。Productテーブル、valueテーブル、およびフィールド名とデータタイプを一覧表示するメタテーブルです（Product.PriceやProduct.Priceメタデータなどの他のテーブルがあるため、データタイプを一覧表示します。 Product.Photoのような他の人と一緒に。）顧客は、競合他社のパーセントオフの差やその場での計算など、あらゆる種類の価格を追跡します。

現在、C＃でLinqtoSQLを使用しています。

編集：

以下の「動的クエリ」Linqが好きです。私たちのDBの背後にある考え方は、ロッカールームのロッカーストレージのようなものです。各アスリート（またはお客様）は、ご希望の方法でロッカーを整理し、保管を行っております。彼らが必要なことをすることができる限り、私たちはロッカーに何が入っているかを気にしません。

非常に興味深い...リポジトリに渡されるオブジェクトは動的である可能性がありますか？これは、ファクトリパターンのように、ほとんど意味があります。お客様が独自のクラス定義をテキストファイルに入れて、それらを継承してDBに保存することは可能でしょうか？

これは別の質問について少し話し合うきっかけになったようで、私はそれ自身の質問にスピンする価値があると思いました。

DRYの原則は、メンテナンスの問題と戦うための私たちの選択の武器のようですが、テストコードのメンテナンスについてはどうでしょうか。同じ経験則が適用されますか？

開発者テストコミュニティのいくつかの強い声は、セットアップと分解は有害であり、避けるべきであるという意見です...いくつか例を挙げると：

• ジェームス・ニューカーク
• ジェイフィールズ、[ 2 ]

実際、xUnit.netは、まさにこの理由でフレームワークからそれらを完全に削除しました（ただし、この自主的な制限を回避する方法はあります）。

あなたの経験は何ですか？セットアップ/ティアダウンは、保守性のテストに悪影響を及ぼしますか、それとも役立ちますか？

更新：JUnit4やTestNG（@ BeforeClass、@ BeforeGroupsなど）で利用できるようなよりきめ細かい構造が違いを生むでしょうか？