design-patterns - Builder Design パターンと Factory Design パターンの違いは何ですか?

Question

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

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

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

score 540 · Accepted Answer

設計パターンでは、通常、すべてのケースで機能する「より有利な」ソリューションはありません。何を実装する必要があるかによって異なります。

ウィキペディアから:

Builder は、複雑なオブジェクトを段階的に構築することに重点を置いています。Abstract Factory は、製品オブジェクトのファミリ (単純または複雑) を強調します。Builder は最終ステップとして製品を返しますが、Abstract Factory に関する限り、製品はすぐに返されます。

Builder は、多くの場合、コンポジットを構築します。

多くの場合、設計は Factory Method (より単純で、カスタマイズ可能で、サブクラスが急増) を使用して開始され、設計者がより柔軟性が必要な場所を発見するにつれて、Abstract Factory、Prototype、または Builder (より柔軟でより複雑) に進化します。

作成パターンが補完的な場合もあります。Builder は他のパターンの 1 つを使用して、ビルドされるコンポーネントを実装できます。抽象ファクトリ、ビルダー、およびプロトタイプは、実装でシングルトンを使用できます。

ファクトリデザインパターンの Wikipedia エントリ: http://en.wikipedia.org/wiki/Factory_method_pattern

ビルダーデザインパターンのウィキペディアエントリ: http://en.wikipedia.org/wiki/Builder_pattern

score 450 · Accepted Answer

ファクトリは、コンストラクタ (おそらく別のクラスのコンストラクタ) の単なるラッパー関数です。主な違いは、ファクトリメソッドパターンでは、オブジェクト全体を 1 回のメソッド呼び出しで構築し、すべてのパラメーターを 1 行で渡す必要があることです。最終的なオブジェクトが返されます。

一方、ビルダーパターンは、本質的に、コンストラクター呼び出しに渡す可能性のあるすべてのパラメーターのラッパーオブジェクトです。これにより、セッターメソッドを使用してパラメーターリストをゆっくりと構築できます。ビルダークラスの 1 つの追加メソッドは build() メソッドです。このメソッドは、単にビルダーオブジェクトを目的のコンストラクターに渡し、結果を返します。

Java のような静的言語では、パラメーターのすべての可能な組み合わせに対してテレスコピックコンストラクターを使用する必要がなくなるため、(潜在的にオプションの) パラメーターが多数ある場合、これはより重要になります。また、ビルダーを使用すると、setter メソッドを使用して、コンストラクターが呼び出された後に直接変更できない読み取り専用またはプライベートフィールドを定義できます。

基本的な工場の例

// Factory
static class FruitFactory {
    static Fruit create(name, color, firmness) {
        // Additional logic
        return new Fruit(name, color, firmness);
    }
}

// Usage
Fruit fruit = FruitFactory.create("apple", "red", "crunchy");

基本ビルダーの例

// Builder
class FruitBuilder {
    String name, color, firmness;
    FruitBuilder setName(name)         { this.name     = name;     return this; }
    FruitBuilder setColor(color)       { this.color    = color;    return this; }
    FruitBuilder setFirmness(firmness) { this.firmness = firmness; return this; }
    Fruit build() {
        return new Fruit(this); // Pass in the builder
    }
}

// Usage
Fruit fruit = new FruitBuilder()
        .setName("apple")
        .setColor("red")
        .setFirmness("crunchy")
        .build();

次の 2 つのウィキペディアページのコードサンプルを比較する価値があるかもしれません。

http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Builder_pattern

score 305 · Accepted Answer

Factory パターンは、ほぼ Builder パターンの単純化されたバージョンと見なすことができます。

ファクトリパターンでは、ファクトリは必要に応じてオブジェクトのさまざまなサブタイプの作成を担当します。

ファクトリメソッドのユーザーは、そのオブジェクトの正確なサブタイプを知る必要はありません。ファクトリメソッドの例として、または型指定されたオブジェクトcreateCarが返されることがあります。FordHonda

Builderパターンでは、さまざまなサブタイプもビルダーメソッドによって作成されますが、オブジェクトの構成は同じサブクラス内で異なる場合があります。

車の例を続けると、 4 気筒エンジンの型オブジェクト、または 6 気筒エンジンの型オブジェクトcreateCarを作成するビルダーメソッドがあるとします。ビルダーパターンは、このより細かい粒度を可能にします。HondaHonda

Builder パターンとFactory メソッドパターンの両方の図は、Wikipedia で入手できます。

score 68 · Accepted Answer

ビルダーデザインパターンは、特定のタイプの別のオブジェクトをいくつかの手順で作成する方法を知っているオブジェクトを記述します。各中間ステップでターゲット項目に必要な状態を保持します。StringBuilder が最終的な文字列を生成するために何をするか考えてみてください。

ファクトリデザインパターンは、特定のタイプが特定のパラメーターに基づいて選択される、1 つのステップでいくつかの異なるが関連する種類のオブジェクトを作成する方法を知っているオブジェクトを記述します。シリアライザーを作成すると、目的の in オブジェクトがすべて 1 回のロード呼び出しで構築されるシリアライゼーションシステムについて考えてみてください。

score 57 · Accepted Answer

複雑なオブジェクトを段階的に構築する : ビルダーパターン
単純なオブジェクトは、単一のメソッドを使用して作成されます: ファクトリメソッドパターン
複数のファクトリメソッドを使用してオブジェクトを作成する : 抽象ファクトリパターン

score 20 · Accepted Answer

どちらも Object を作成するための Creational パターンです。

1) ファクトリパターン - 1 つのスーパークラスと N 個のサブクラスがあるとします。作成されるオブジェクトは、渡されるパラメーター/値によって異なります。

2) ビルダーパターン - 複雑なオブジェクトを作成します。

Ex: Make a Loan Object. Loan could be house loan, car loan ,
    education loan ..etc. Each loan will have different interest rate, amount ,  
    duration ...etc. Finally a complex object created through step by step process.

score 7 · Accepted Answer

私が理解できた Builder と factory の顕著な違いの 1 つは、次のとおりです。

私たちは車を持っているとしましょう

class Car
{
  bool HasGPS;
  bool IsCityCar;
  bool IsSportsCar;
  int   Cylenders;
  int Seats;

  public:
     void Car(bool hasGPs=false,bool IsCityCar=false,bool IsSportsCar=false, int Cylender=2, int Seats=4);
 };

上記のインターフェイスでは、次の方法で車を取得できます。

 int main()
 {
    BadCar = new Car(false,false,true,4,4);
  }

しかし、座席の作成中に何らかの例外が発生した場合はどうなりますか??? あなたはまったくオブジェクトを取得しません // しかし

次のような実装があるとします

class Car
 {
    bool mHasGPS;
    bool mIsCityCar;
    bool mIsSportsCar;
    int mCylenders;
    int mSeats;

 public:
    void Car() : mHasGPs(false), mIsCityCar(false), mIsSportsCar(false), mCylender(2), mSeats(4) {}
    void SetGPS(bool hasGPs=false)  {mHasGPs = hasGPs;}
    void SetCity(bool CityCar)  {mIsCityCar = CityCar;}
    void SetSports(bool SportsCar)  {mIsSportsCar = SportsCar;}
    void SetCylender(int Cylender)  {mCylenders = Cylender;}    
    void SetSeats(int seat) {mSeats = seat;}    
};

 class CarBuilder 
 {
    Car* mCar;
public:
        CarBuilder():mCar(NULL) {   mCar* = new Car();  }
        ~CarBuilder()   {   if(mCar)    {   delete mCar;    }
        Car* GetCar()   {   return mCar; mCar=new Car();    }
        CarBuilder* SetSeats(int n) {   mCar->SetSeats(n); return this; }
        CarBuilder* SetCylender(int n)  {   mCar->SetCylender(n); return this;  }
        CarBuilder* SetSports(bool val) {   mCar->SetSports(val); return this;  }
        CarBuilder* SetCity(bool val)   {   mCar->SetCity(val); return this;    }
        CarBuilder* SetGPS(bool val)    {   mCar->SetGPS(val); return this; }
}

今、あなたはこのように作成することができます

 int main()
 {
   CarBuilder* bp =new CarBuilder;
    Car* NewCar  = bp->SetSeats(4)->SetSports(4)->SetCity(ture)->SetGPS(false)->SetSports(true)->GetCar();

     bp->SetSeats(2);

     bp->SetSports(4);

     bp->SetCity(ture);

     bp->SetSports(true)

     Car* Car_II=  bp->GetCar();

  }

ここで 2 番目のケースでは、1 つの操作が失敗しても Car を取得できます。

その車は後で完全に機能しないかもしれませんが、あなたはオブジェクトを持っているでしょう.

Factory Method は Car を 1 回の呼び出しで提供するのに対し、Builder は 1 つずつビルドするためです。

ただし、どちらを選択するかは設計者のニーズによって異なります。

score 5 · Accepted Answer

BuilderとAbstract Factoryは、異なる目的を意味しています。適切なユースケースに応じて、適切なデザインパターンを選択する必要があります。

ビルダーの顕著な特徴:

Builder パターンは、単純なオブジェクトを使用し、段階的なアプローチを使用して複雑なオブジェクトを構築します
Builder クラスは、最終的なオブジェクトを段階的に構築します。このビルダーは他のオブジェクトから独立しています
このシナリオでのファクトリメソッド/アブストラクトファクトリへの置き換え: クライアントプログラムからファクトリクラスに渡す引数が多すぎるため、エラーが発生しやすくなります。
一部のパラメーターは、すべてのパラメーターを強制的に送信する Factory とは異なり、オプションである場合があります。

工場(単純な工場) の顕著な特徴:

創作パターン
継承に基づく
Factory は、具象オブジェクトを返す Factory Method (インターフェース) を返します。
インターフェイスを新しい具象オブジェクトに置き換えることができ、クライアント (呼び出し元) はすべての具象実装を認識する必要はありません。
クライアントは常にインターフェイスのみにアクセスし、Factory メソッドでオブジェクト作成の詳細を非表示にできます。

多くの場合、設計はFactory Method (より単純でカスタマイズ可能で、サブクラスが急増) を使用して開始され、 Abstract Factory、Prototype、またはBuilder (より柔軟でより複雑)に進化します。

関連する投稿を見てください：

ビルダーを別のクラスに保持する (流暢なインターフェース)

デザインパターン: ファクトリ vs ファクトリメソッド vs 抽象ファクトリ

詳細については、以下の記事を参照してください。

ソースメイキング

ジャーナル開発

score 2 · Accepted Answer

Factory と Builder のパターンの使用法とその違いは、同じコードベースで作業し、要件を変更することで、特定の期間でより簡単に理解/明確化できると思います。

私の経験から、通常は、主に比較的複雑な初期化ロジックを隠すために、いくつかの静的クリエーターメソッドを含む Factory パターンから始めます。オブジェクト階層がより複雑になるにつれて (または、より多くの型やパラメーターを追加するにつれて)、おそらくより多くのパラメーターがメソッドに入力されることになり、Factory モジュールを再コンパイルする必要があることは言うまでもありません。これらすべてのものは、作成者メソッドの複雑さを増し、可読性を低下させ、作成モジュールをより脆弱にします。

このポイントは、移行/拡張ポイントになる可能性があります。そうすることで、構築パラメーターの周りにラッパーモジュールを作成し、実際の作成ロジックに触れることなく、抽象化 (おそらく) と実装を追加することで、新しい (類似の) オブジェクトを表すことができます。したがって、複雑なロジックが「少なく」なりました。

率直に言って、「1 つのステップまたは複数のステップで作成されたオブジェクトを持つことの違い」のようなものを参照するだけでは、それらを区別するのに十分ではありませんでした。今は何のメリットもありません。そこで、最終的に考えたのがこれです。

score 1 · Accepted Answer

どちらも非常によく似ていますが、オブジェクト作成用のパラメーターが多数あり、そのうちのいくつかはオプションで、いくつかのデフォルト値がある場合は、Builder パターンを使用してください。

score 1 · Accepted Answer

ビルドパターンは、オブジェクト作成の複雑さ を強調します (「ステップ」によって解決されます)。

抽象パターンは、(複数だが関連する) オブジェクトの「抽象化」の「ちょうど」を強調します。

score 1 · Accepted Answer

私見では

Builder は、ある種のより複雑な Factory です。

ただし、ビルダーでは、最終的で有効なオブジェクトを構築するために必要な別の factory を使用してオブジェクトをインスタンス化できます。

したがって、複雑さによる「創造的パターン」の進化について話すと、次のように考えることができます。

Dependency Injection Container -> Service Locator -> Builder -> Factory

score 0 · Accepted Answer

私の意見では、ビルダーパターンは、他のオブジェクトの束からオブジェクトを作成したい場合に使用され、パーツの作成は、作成するオブジェクトとは独立している必要があります。パーツの作成をクライアントから隠して、ビルダーとクライアントを独立させるのに役立ちます。複雑なオブジェクトの作成に使用されます (複雑なプロパティで構成されるオブジェクト)

ファクトリパターンは、共通のファミリのオブジェクトを作成することを指定し、それを一度に生成することを指定します。より単純なオブジェクトに使用されます。

score 0 · Accepted Answer

違いは明らかですビルダーパターンでは、ビルダーは特定のタイプのオブジェクトを作成します。どのビルダーがビルドする必要があるかを指定する必要があります。factory pattern では、抽象クラスを使用して、特定のオブジェクトを直接構築しています。

ここでビルダークラスは、メインクラスと特定の型クラスの間のメディエーターとして機能します。さらなる抽象化。

score 0 · Accepted Answer

ビルダーと抽象ファクトリー

Builder デザインパターンは、Abstract Factory パターンにある程度似ています。そのため、どちらを使用するかによって状況を区別できることが重要です。抽象ファクトリの場合、クライアントはファクトリのメソッドを使用して独自のオブジェクトを作成します。Builder の場合、オブジェクトの作成方法を Builder クラスに指示してから要求しますが、クラスの組み立て方は Builder クラス次第であり、この点で 2 つのパターンの違いが生じます。

製品共通インターフェース

実際には、コンクリートビルダーによって作成された製品は構造が大きく異なるため、異なる製品を共通の親クラスから派生させる理由がない場合。これはまた、Builder パターンを、共通の型から派生したオブジェクトを作成する Abstract Factory パターンと区別します。

から: http://www.oodesign.com/builder-pattern.html

score 0 · Accepted Answer

多くの設計は、Factory Method (複雑ではなく、サブクラスを介してよりカスタマイズ可能) を使用することから始まり、 Abstract Factory、Prototype、またはBuilder (より柔軟ですが、より複雑) に向かって進化します。

Builderは、複雑なオブジェクトを段階的に構築することに重点を置いています。

それを実装する：

利用可能なすべての製品表現を構築するための一般的な構築手順を明確に定義します。そうしないと、パターンの実装に進むことができません。
ベースビルダーインターフェイスでこれらの手順を宣言します。
製品表現ごとに具体的なビルダークラスを作成し、それらの構築手順を実装します。

Abstract Factoryは、関連するオブジェクトのファミリの作成を専門としています。Abstract Factoryは製品をすぐに返しますが、Builder は製品を取得する前にいくつかの追加の構築ステップを実行できます。

Bridgeと一緒にAbstract Factoryを使用できます。この組み合わせは、Bridge によって定義された一部の抽象化が特定の実装でのみ機能する場合に役立ちます。この場合、Abstract Factory はこれらの関係をカプセル化し、複雑さをクライアントコードから隠すことができます。

デザインパターンに飛び込む

score -2 · Accepted Answer

ファクトリパターンでは一度に一度にオブジェクトを作成できますが、ビルダーパターンではオブジェクトの作成プロセスを中断できます。このようにして、オブジェクトの作成中にさまざまな機能を追加できます。

design-patterns - Builder Design パターンと Factory Design パターンの違いは何ですか?

27 に答える 27

ビルダーと抽象ファクトリー

製品共通インターフェース

Related

Reference