web-dev-qa-db-ja.com

なぜ抽象的な工場設計パターンが必要なのですか？

定義のほとんどは次のとおりです。

抽象ファクトリーは、具象クラスを指定せずに関連オブジェクトのファミリーを作成するためのインターフェースを提供します

具象クラス自体のオブジェクトを作成することでタスクを達成できるので、Abstract Factory Patternの使用とは何ですか。なぜConcreteクラスのオブジェクトを作成するファクトリーメソッドがあるのですか？

AbstractFactoryパターンを実装する必要がある実際の例を教えてください。

design-patternsabstract-factory
115
Amit

Abstract Factoryは、Dependency Injection（DI）の非常に中心的な設計パターンです。以下は、Abstract FactoryのアプリケーションがソリューションとしてacceptedであるStack Overflowの質問のリストです。

私の理解する限りでは、これらの質問は人々が抱えていた本当の懸念や問題を表しているので、実際の例から始めましょう。

212
Mark Seemann

Abstract Factoryパターンの使用の実際の例は、2つの異なるデータソース（たとえば、SQLデータベースとXMLファイル）へのデータアクセスを提供しています。 2つの異なるデータアクセスクラス（データストアへのゲートウェイ）があります。どちらも、実装する共通メソッド（Load、Save、Deleteなど）を定義する基本クラスから継承します。

どのデータソースを使用するかは、クライアントコードがデータアクセスクラスを取得する方法を変更してはなりません。抽象ファクトリは、使用するデータソースを認識し、要求に応じて適切なインスタンスを返します。ファクトリは、このインスタンスを基本クラスタイプとして返​​します。

22
Johannes Rudolph

私があなたを正しく理解している場合-質問は、なぜFactoryメソッドと抽象ファクトリパターンの両方があるのか​​ということです。異なるポリモーフィッククラスに異なるインスタンス化プロシージャがある場合、抽象ファクトリが必要です。また、オブジェクトの初期化の詳細を知らなくても、いくつかのモジュールでインスタンスを作成して使用する必要があります。たとえば、Javaいくつかの計算を行うオブジェクトを作成します。ただし、それらの一部はアプリケーションの一部であり、他のバイトコードはDBから読み取る必要があります。ファクトリメソッドが必要ですか？同意しますが、抽象ファクトリはオーバーラップしますが、場合によっては、記述するコードがはるかに少なく、クラスとインターフェイスが少ないため、システムを理解しやすくなります。

5
David Gruzman

具体的なクラス自体のオブジェクトを作成することでタスクを達成できるので、Abstract Factory Patternの使用とは何ですか。 Concreteクラスのオブジェクトを作成するファクトリーメソッドがあるのはなぜですか？

Abstract Factoryがない場合、クライアントは具象クラスの詳細を知る必要があります。この密結合はAbstract Factoryで削除されました。

Factory Methodは、クライアントが使用する必要があるコントラクトを公開します。 Factory Methodによって公開されるインターフェースを実装する新しい製品を追加することにより、工場にさらに製品を追加できます。

理解を深めるために、これらの関連するSEの質問を参照してください。

FactoryとAbstract Factoryパターンの基本的な違いは何ですか？

意図：

具象クラスを指定せずに、関連オブジェクトまたは依存オブジェクトのファミリーを作成するためのインターフェースを提供します。

この sourcemaking 記事から意図、構造、チェックリスト、および経験則 of Abstract Factoryパターンを理解できます。

チェックリスト：

  1. プラットフォーム独立および作成サービスが現在の痛みの原因であるかどうかを判断します。
  2. プラットフォーム対製品）のマトリックスを作成します。
  3. 製品ごとのファクトリメソッドで構成されるfactory interfaceを定義します。
  4. 新しい演算子へのすべての参照をカプセル化する各プラットフォームのfactory派生クラスを定義します。
  5. clientは、newへのすべての参照を廃止し、factory methodsを使用してproductオブジェクトを作成します。
3
Ravindra babu

抽象ファクトリーは、コードベースを統一したまま複数のプラットフォームをサポートするのに最適です。 Windows、Linux、およびOSXで実行したい大きなQtまたはGTK +または.NET/Monoプログラムがあるとします。ただし、プラットフォームごとに異なる方法で実装される機能があります（おそらくkernel32 APIまたはPOSIX機能を介して）。

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

この抽象ファクトリーを使用すると、UIは現在のプラットフォームについて何も知る必要がありません。

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);
2
piedar

設計パターンを見ると、それらのほとんどすべてを冗長化できます。しかし、どのようなパターンが、同様のタイプの問題の解決に一般的に使用されるアプローチを意味します。設計パターンは、一連の同様のタイプの設計問題に対する設計レベルのアプローチまたはソリューションを提供します。設計パターンを使用すると、問題を解決するのに役立ち、したがって、より迅速に配信できます。

1
Kangkan

抽象化で動作するコードがあることをイメージするのは簡単です。具体的なクラスではなく抽象化を作成する必要があります。

コードをより適切に変更できるため、常に抽象化に対処する必要があります。

これは良い例です： http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.2

1
Pablo Castilla

インスタンス化が非常に複雑で、単一のファクトリーでは複雑すぎてtooく、UIが理解するには複雑すぎる場所には、単純なファクトリーパターンではなく抽象的なファクトリーパターンの場所があると思います。

これが単一クラスではなくTYPE_Aブランドであるとしましょう。タイプAの類似したクラスが100種類あり、それらから1つのオブジェクトをインスタンス化する必要があるとしましょう。多くの類似したタイプのオブジェクトのブランドから正しいオブジェクトを作成するために必要な詳細な詳細情報があり、このオブジェクトエンティティでは、調整するパラメーターとその調整方法を正確に知る必要があると想像してください。

このブランドの特別な工場では、インスタンス化するオブジェクトとインスタンス化する方法を区別して取得します。ネットからの入力（オンラインストアで利用可能な色を言う）と、バックグラウンドで実行されている他のアプリケーションやサービス（UIが認識しないパラメーター）からの入力を知ることができます。

そして明日、type_Bとtype_Cの別のファミリーをインスタンス化することになります。したがって、UIには、ユーザーが「type_A」、「type_B」、または「type_C」を望むかどうかを知るための「if else」がありますが、ファクトリクラスは、タイプ（ファミリー）から構築するクラスを正確に決定します。調整方法-パラメーターに設定する値、または請負業者に送信する値。このすべて-UIが認識していない多くのパラメーターによる。これはすべて、単一のファクトリクラスには多すぎます。

1
Udi Reshef

Abstract Factoryパターンが過大評価されています。

まず第一に、それは起こりませんthat多くの場合、インスタンス化したいinterrelatedタイプのセットがあります。

第二に、依存性注入を使用する場合、通常、interfacesによって提供される間接化（抽象化）のレベルで十分です。

WindowsGui vs MacGui vs ...の典型的な例では、WindowsButton、MacButton、WindowsScrollBar、MacScrollbarなどを使用します。Visitorを使用してconcrete Buttons、Scrollbarsなどを定義することにより、実装が簡単になることがよくあります。および/または実際の動作を提供する通訳パターン。

0
eljenso

A.jarを作成し、他の誰かがjarを使用していて、コード内で新しい具象オブジェクトを使用したいとします。抽象ファクトリを使用していない場合、彼女はコードを変更するか、コードを上書きする必要があります。ただし、抽象ファクトリを使用している場合は、ファクトリを提供してコードに渡すことができ、すべてが問題ありません。

改良版：以下のシナリオを検討してください：他の誰かがフレームワークを作成しました。このフレームワークは、抽象ファクトリーといくつかの具体的なファクトリーを使用して、実行時に多くのオブジェクトを作成します。したがって、独自のファクトリを既存のフレームワークに簡単に登録し、独自のオブジェクトを作成できます。このフレームワークは修正が禁止されており、抽象的なファクトリパターンのために拡張が容易です。

0
Adrian Liu

依存関係がすべてです。密結合と依存関係を気にしないのであれば、抽象ファクトリーは必要ありません。ただし、メンテナンスが必要なアプリケーションを作成するとすぐに問題になります。

0
Daniel

このパターンは、クライアントが作成するタイプを正確に知らない場合に特に役立ちます。例として、携帯電話のみを販売するショールームが、サムスン製のスマートフォンのクエリを取得したとしましょう。ここでは、作成されるオブジェクトの正確なタイプはわかりません（電話のすべての情報が具体的なオブジェクトの形式でラップされていると仮定します）。しかし、私たちはサムスン製のスマートフォンを探していることを知っています。この情報は、設計に抽象ファクトリー実装がある場合に実際に利用できます。

C＃での抽象ファクトリパターンの理解と実装

0
Amir Shabani

あなたの質問に直接答えるために、おそらくそのようなデザインパターンを使わずに逃げることができます。

ただし、現実世界のプロジェクトのほとんどは進化しているため、プロジェクトを将来にわたって使用できるようにするために、何らかの拡張性を提供する必要があります。

私自身の経験から、ほとんどの場合、ファクトリは実装され、プロジェクトが成長するにつれて、抽象ファクトリなどのより複雑な設計パターンに変更されます。

0
BlueTrin