タグ付けされた質問 「factory-method」

最終的にいくつかの基本的なパターンを習おうと真剣に始めたので（キャリアの非常に遅いですが、それは別の話です）、私はファクトリーパターンとアブストラクトファクトリーの違いを理解しようとしています。 これら2つのパターンの主な違いは何ですか？ Factoryメソッドは継承を介してオブジェクトを作成し、Abstract Factoryはオブジェクトの構成を介してオブジェクトを作成することを理解していますが、実際的な観点からは、それぞれがどのように機能するかを正確に視覚化するのにまだ苦労しています。

40 design-patterns  factory-method 

私はHeadingいくつかのことを行うと呼ばれるクラスを持っていますが、現在の見出し値の反対を返すこともできるはずであり、Headingクラス自体の新しいインスタンスを作成することで最終的に使用する必要があります。 reciprocal現在の値の反対の見出しを返すために呼び出される単純なプロパティを使用して、Headingクラスの新しいインスタンスを手動で作成するか、HeadingクラスcreateReciprocalHeading()の新しいインスタンスを自動的に作成してそれを返すようなメソッドを作成できますユーザー。 しかし、私の同僚の1だけでクラスを作成するために私をお勧めプロパティと呼ばれるreciprocalそのgetterメソッドを介したクラス自体の新しいインスタンスを返すことを。 私の質問は次のとおりです。クラスのプロパティがそのように動作するのはアンチパターンではありませんか？ 私は特に以下の理由で直観的ではないと思います： 私の考えでは、クラスのプロパティはクラスの新しいインスタンスを返すべきではありません。 reciprocalIDEからヘルプを得たり、ゲッター署名を確認したりせずに、プロパティの名前であるが、開発者がその動作を完全に理解するのに役立ちません。 クラスプロパティが何をすべきかについて厳格すぎるのですか、それとも有効な懸念事項ですか？私は常にフィールドとプロパティを介してクラスの状態を管理しようとし、メソッドを介してその動作を管理しようとしましたが、これがクラスプロパティの定義にどのように適合するかはわかりません。

24 object-oriented  factory-method 

私のコードのいくつかでは、次のような静的ファクトリーがあります。 public class SomeFactory { // Static class private SomeFactory() {...} public static Foo createFoo() {...} public static Foo createFooerFoo() {...} } コードのレビュー中に、これはシングルトンであることが提案され、注入されました。したがって、次のようになります。 public class SomeFactory { public SomeFactory() {} public Foo createFoo() {...} public Foo createFooerFoo() {...} } 強調すべきいくつかのこと： 両方の工場はステートレスです。 メソッド間の唯一の違いは、スコープ（インスタンスと静的）です。実装は同じです。 Fooは、インターフェースを持たないBeanです。 静的にするための引数は次のとおりです。 クラスはステートレスであるため、インスタンス化する必要はありません ファクトリをインスタンス化するよりも静的メソッドを呼び出す方が自然なようです シングルトンとしてのファクトリの引数は次のとおりです。 すべてを注入するのが良い 工場の無国籍にもかかわらず、注入によりテストが簡単になります（簡単にモックできます） 消費者をテストするとき、それはock笑されるべきです …

24 java  design-patterns  singleton  factory-method 

問題 ファイルからデータを読み取るためのメソッドDataSourceを提供するクラスReadData（および他のクラスもありますが、物事をシンプルにしましょう）があるとし.mdbます。 var source = new DataSource("myFile.mdb"); var data = source.ReadData(); 数年後、データソースとして.xmlファイルに加えて.mdbファイルもサポートできるようにしたいと決めました。「データの読み取り」の実装は.xml、.mdbファイルとファイルでまったく異なります。したがって、システムをゼロから設計する場合、次のように定義します。 abstract class DataSource { abstract Data ReadData(); static DataSource OpenDataSource(string fileName) { // return MdbDataSource or XmlDataSource, as appropriate } } class MdbDataSource : DataSource { override Data ReadData() { /* implementation 1 */ } } class XmlDataSource …

15 c#  design-patterns  refactoring  factory-method 

インジェクションを受け入れるのではなく、依存関係を直接構築するクライアントが1001人いるとします。上司によると、1001のリファクタリングはオプションではありません。実際には、ソースへのアクセスさえ許可されていません。クラスファイルだけです。 私たちがやるべきことは、これらの1001クライアントが通過するシステムを「近代化」することです。好きなことをリファクタリングできます。依存関係はそのシステムの一部です。そして、それらの依存関係のいくつかは、新しい実装を行うために変更することになっています。 私たちがやりたいことは、この多数のクライアントを満たすために、依存関係の異なる実装を構成する機能を持っていることです。悲しいことに、クライアントはコンストラクターまたはセッターによるインジェクションを受け入れないため、DIはオプションのようには見えません。 オプション： 1）クライアントが使用するサービスの実装をリファクタリングして、クライアントが現在必要としていることを行うようにします。完了です。柔軟ではありません。複雑ではありません。 2）実装をリファクタリングして、ファクトリを通じて取得したさらに別の依存関係に作業を委任します。これで、ファクトリをリファクタリングすることで、すべてが使用する実装を制御できます。 3）実装をリファクタリングして、作業をサービスロケーターを介して取得したさらに別の依存関係に委任します。これhashmapで、少しのキャストが行われたオブジェクトへの文字列である可能性のあるサービスロケーターを構成することで、すべてが使用する実装を制御できます。 4）まだ考えていないこと。 目的： 設計が不十分な古いクライアントコードを無意味な複雑さを加えることなく未来にドラッグすることによって引き起こされる設計の損傷を最小限に抑えます。 クライアントは依存関係の実装を知っていないか制御するべきではありませんが、で構築することを主張しますnew。制御することはできませんnewが、構築しているクラスを制御します。 私の質問： 何を考慮しなかったのですか？ Doc Brownからの質問 異なる実装間で構成する可能性が本当に必要ですか？何のために？ 機敏。未知の多く。経営陣は変化の可能性を望んでいます。外の世界への依存を失うだけです。またテスト。 実行時の仕組みが必要ですか、それとも異なる実装を切り替えるためにコンパイル時の仕組みが必要ですか？どうして？ コンパイルの時間の仕組みで十分です。テストを除く。 どの粒度で実装を切り替える必要がありますか？一斉に？モジュールごと（それぞれがクラスのグループを含む）？クラスごと？ 1001のうち、一度に実行されるのは1つだけです。すべてのクライアントが一度に使用するものを変更しても問題はないでしょう。ただし、依存関係を個別に制御することはおそらく重要です。 誰がスイッチを制御する必要がありますか？あなた/あなたの開発者チームのみ？管理者ですか？各クライアントは自分で？または、クライアントのコードのメンテナンス開発者ですか？それでは、メカニックはどれほど簡単/堅牢/完全に機能する必要があるのでしょうか？ テスト用の開発。外部ハードウェアの依存関係が変化するため、管理者。テストと構成が簡単である必要があります。 私たちの目標は、システムを迅速に作り直し、近代化できることを示すことです。 実装スイッチの実際の使用例 1つは、ハードウェアソリューションの準備が整うまで、一部のデータがソフトウェアによって提供されることです。

14 design  refactoring  dependency-injection  factory-method  service-locator 

このShapeFactoryが条件付きステートメントを使用して、インスタンス化するオブジェクトを決定するのはなぜですか。将来他のクラスを追加する場合、ShapeFactoryを変更する必要はありませんか？なぜこれはオープンクローズド原則に違反しないのですか？

13 design  design-patterns  factory-method  factory 

だから私は異なるクラスのオブジェクトを作成するファクトリーを持っています。可能なクラスはすべて抽象祖先から派生しています。ファクトリーには構成ファイル（JSON構文）があり、ユーザーの構成に応じて、作成するクラスを決定します。 これを実現するために、ファクトリはJSON解析にboost :: property_treeを使用します。彼はptreeをウォークスルーし、どの具象オブジェクトを作成するかを決定します。 ただし、製品オブジェクトには多くのフィールド（属性）があります。具体的なクラスにもよりますが、オブジェクトには約5〜10個の属性があり、将来的にはさらに増える可能性があります。 そのため、オブジェクトのコンストラクターがどのように見えるかわかりません。私は2つの解決策を考えることができます： 1）製品のコンストラクターはすべての属性をパラメーターとして想定しているため、コンストラクターは最終的に10個以上のパラメーターになります。これは醜く、長くて読めないコード行につながります。ただし、利点は、ファクトリーがJSONを解析し、正しいパラメーターでコンストラクターを呼び出すことができることです。製品クラスは、JSON構成のために作成されたことを知る必要はありません。JSONや設定が含まれていることを知る必要はありません。 2）製品のコンストラクターは、property_treeオブジェクトという1つの引数のみを想定しています。次に、必要な情報を解析できます。構成内の情報が欠落しているか範囲外の場合、各製品クラスは適切に対応できます。ファクトリは、いくつかの製品に必要な引数を知る必要はありません。ファクトリーは、誤った構成の場合の対応方法を知る必要もありません。また、コンストラクターインターフェイスは統一されており、小さいです。ただし、デメリットとして、製品は必要な情報をJSONから抽出する必要があるため、JSONがどのように構成されているかを認識しています。 私は解決策2）を好む傾向があります。ただし、これが適切なファクトリパターンであるかどうかはわかりません。JSON構成で作成されていることを製品に通知するのは、どういうわけか間違っていると感じます。一方、新製品は非常に簡単に導入できます。 それについての意見はありますか？

10 design-patterns  object-oriented  c++  architectural-patterns  factory-method 

2つの間の類似点と相違点： テンプレートメソッド 継承に依存します。 アルゴリズムのステップを定義し、それらを実装するタスクをサブクラスに任せます。 ファクトリーメソッド 継承に依存します。 スーパークラスは、オブジェクトを作成するためのインターフェースを定義します。サブクラスは、インスタンス化する具象クラスを決定します。 2つ並べて： 「ファクトリーメソッドはテンプレートメソッドの特殊化」というフレーズの意味がわかりません（Head First Design Patternsブックにあります）。ではBeverage、私たちの方法持ってprepareいるfinalと一連の手順を定義します。にPizzaStoreあるメソッドがありabstract、サブクラスがそれを再定義します。後者は前者を特化したものですか？

10 design-patterns  object-oriented-design  factory-method  template-method