Question Quelle est la différence entre le modèle de conception de générateur et le modèle de conception d'usine?


Quelle est la différence entre le modèle de conception du générateur et le modèle de conception d'usine?

Lequel est le plus avantageux et pourquoi?

Comment puis-je représenter mes résultats sous forme de graphique si je veux tester et comparer / contraster ces modèles?


472
2018-04-16 19:39


origine


Réponses:


Avec les modèles de conception, il n'y a généralement pas de solution «plus avantageuse» qui fonctionne dans tous les cas. Cela dépend de ce que vous devez implémenter.

De Wikipedia:

  • Builder se concentre sur la construction d'un   objet complexe pas à pas. Abstrait   Factory met l'accent sur une famille de produits   objets (simples ou complexes).   Builder renvoie le produit en tant que final   étape, mais aussi loin que l'abrégé   Factory est concerné, le produit obtient   retourné immédiatement.
  • Générateur construit souvent un composite.
  • Souvent, les conceptions commencent à utiliser la méthode d'usine (moins compliquée, plus   personnalisable, les sous-classes prolifèrent)   et évoluer vers Abstract Factory,   Prototype ou Builder (plus flexible,   plus complexe) en tant que concepteur   découvre où plus de flexibilité est   nécessaire.
  • Parfois, les modèles de création sont complémentaires: le constructeur peut en utiliser un   des autres modèles à mettre en œuvre   quels composants sont construits. Abstrait   Factory, Builder et Prototype peuvent   utiliser Singleton dans leur   implémentations.

Entrée de Wikipedia pour le motif de conception d'usine: http://en.wikipedia.org/wiki/Factory_method_pattern

Entrée de Wikipédia pour le motif de conception de builder: http://en.wikipedia.org/wiki/Builder_pattern


342
2018-04-16 19:46



Le motif Factory peut presque être considéré comme une version simplifiée du motif Builder.

dans le Usine modèle, l'usine est chargée de créer différents sous-types d'un objet en fonction des besoins.

L'utilisateur d'une méthode d'usine n'a pas besoin de connaître le sous-type exact de cet objet. Un exemple de méthode d'usine createCar pourrait retourner un Ford ou un Honda objet tapé.

dans le Constructeur pattern, différents sous-types sont également créés par une méthode de construction, mais la composition des objets peut différer au sein de la même sous-classe.

Pour continuer l'exemple de voiture, vous pourriez avoir un createCar méthode de création qui crée un Honda-typed object avec un moteur 4 cylindres, ou un Hondaobjet de type 6 cylindres. Le modèle de générateur permet cette granularité plus fine.

Diagrammes des deux Modèle de constructeur et le Modèle de méthode d'usine sont disponibles sur Wikipedia.


233
2018-04-16 19:44



Une usine est simplement une fonction wrapper autour d'un constructeur (éventuellement un dans une classe différente). La principale différence est qu'un modèle de méthode d'usine nécessite que l'objet entier soit construit dans un seul appel de méthode, avec tous les paramètres transmis sur une seule ligne. L'objet final sera retourné.

Un modèle de constructeur, d'autre part, est essentiellement un objet wrapper autour de tous les paramètres possibles que vous pourriez vouloir passer dans un appel de constructeur. Cela vous permet d'utiliser des méthodes de réglage pour créer lentement votre liste de paramètres. Une méthode supplémentaire sur une classe builder est une méthode build (), qui passe simplement l'objet builder dans le constructeur souhaité, et renvoie le résultat.

Dans les langages statiques comme Java, ceci devient plus important quand vous avez plus d'une poignée de paramètres (potentiellement optionnels), car cela évite d'avoir des constructeurs télescopiques pour toutes les combinaisons possibles de paramètres. De plus, un générateur vous permet d'utiliser des méthodes de définition pour définir des champs en lecture seule ou privés qui ne peuvent pas être directement modifiés après l'appel du constructeur.

Exemple d'usine de base

// 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");

Exemple de générateur de base

// 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();

Il peut être utile de comparer les exemples de code de ces deux pages wikipedia:

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


212
2018-01-22 05:15



Le modèle de conception de générateur décrit un objet qui sait créer un autre objet d'un type spécifique en plusieurs étapes. Il contient l'état nécessaire pour l'élément cible à chaque étape intermédiaire. Pensez à ce que StringBuilder doit produire pour produire une chaîne finale.

Le modèle de conception d'usine décrit un objet qui sait créer plusieurs types d'objets différents mais associés en une seule étape, où le type spécifique est choisi en fonction de paramètres donnés. Pensez au système de sérialisation, où vous créez votre sérialiseur et il construit l'objet désiré dans un appel de chargement.


49
2018-04-16 19:44



  • Construire un objet complexe pas à pas: modèle de générateur

  • Un objet simple est créé en utilisant une seule méthode: modèle de méthode usine

  • Création d'un objet à l'aide de la méthode de fabrication multiple: Motif de fabrique abstrait


35
2018-06-18 06:15



Les deux sont des modèles créatifs, pour créer un objet.

1) Motif d'usine - Supposons que vous ayez une super classe et un nombre N de sous-classes.     L'objet est créé en fonction du paramètre / valeur transmis.

2) Motif Builder - pour créer un objet complexe.

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.

10
2018-04-17 10:00



D'abord certaines choses générales à suivre mon argumentation:

Le principal défi dans la conception de systèmes logiciels volumineux est qu’ils doivent être flexibles et simples à modifier. Pour cette raison, il existe des paramètres tels que le couplage et la cohésion. Pour réaliser des systèmes qui peuvent être facilement modifiés ou étendus dans sa fonctionnalité sans avoir besoin de repenser entièrement le système, vous pouvez suivre les principes de conception (comme SOLID, etc.). Après un certain temps, certains développeurs ont reconnu que s'ils suivaient ces principes, il existe des solutions similaires qui ont bien fonctionné pour des problèmes similaires. Ces solutions standard se sont avérées être les modèles de conception.

Ainsi, les modèles de conception doivent vous aider à suivre les principes généraux de conception afin de réaliser des systèmes faiblement couplés avec une forte cohésion.

Répondre à la question:

En demandant la différence entre deux modèles, vous devez vous demander quel modèle rend votre système plus flexible. Chaque modèle a son propre but d'organiser les dépendances entre les classes de votre système.

Le motif d'usine abstraite: GoF: "Fournir une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes."

Qu'est-ce que ça veut dire: En fournissant une interface comme celle-ci, l'appel au constructeur de chaque produit de la famille est encapsulé dans la classe d'usine. Et parce que c'est le seul endroit de votre système où ces constructeurs sont appelés, vous pouvez modifier votre système en implémentant une nouvelle classe d'usine. Si vous échangez la représentation de l'usine par une autre, vous pouvez échanger tout un ensemble de produits sans toucher à la majorité de votre code.

Le modèle Builder: GoF: "Séparer la construction d'un objet complexe de sa représentation afin que le même processus de construction puisse créer des représentations différentes."

Qu'est-ce que ça veut dire: Vous encapsulez le processus de construction dans une autre classe, appelée le directeur (GoF). Ce directeur contient l'algorithme de création de nouvelles instances du produit (par exemple, composer un produit complexe à partir d'autres parties). Pour créer les parties intégrantes de l'ensemble du produit, le réalisateur utilise un constructeur. En échangeant le constructeur dans le directeur, vous pouvez utiliser le même algorithme pour créer le produit, mais changer les représentations des pièces uniques (et donc la représentation du produit). Pour étendre ou modifier votre système dans la représentation du produit, tout ce que vous devez faire est d'implémenter une nouvelle classe de générateur.

Donc en bref: Le but de Abstract Factory Pattern est d'échanger un ensemble de produits qui sont faits pour être utilisés ensemble. Le but du Builder Pattern est d'encapsuler l'algorithme abstrait de création d'un produit pour le réutiliser pour différentes représentations du produit.

À mon avis, vous ne pouvez pas dire que le modèle d'usine abstrait est le grand frère du modèle Builder. OUI, ils sont tous les deux des modèles de création, mais l'intention principale des modèles est entièrement différente.


8
2018-01-15 17:15



Une différence frappante entre Builder et usine que je pourrais faire était la suivante

supposons que nous ayons une voiture

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);
 };

Dans l'interface ci-dessus, nous pouvons obtenir la voiture de la manière suivante:

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

mais que se passe-t-il si une exception se produit lors de la création des sièges ??? Vous n'obtiendrez pas l'objet du tout // MAIS

Supposons que vous avez une mise en œuvre comme celle-ci

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; }
}

Maintenant vous pouvez créer comme ceci

 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();

  }

Ici, dans le second cas, même si une opération échoue, vous obtiendrez toujours la voiture.

Peut-être que cette voiture ne fonctionne pas parfaitement plus tard mais, vous auriez l'objet.

Parce que la méthode usine vous donne la voiture en appel unique, alors que le constructeur construit un par un.

Bien que cela dépende des besoins du dieu que l'on doit aller.


5
2017-08-22 08:49



C'est un modèle de création car il est utilisé pour contrôler l'instanciation de classe. Le modèle de générateur est utilisé pour créer des objets complexes avec des composants qui doivent être créés dans le même ordre ou en utilisant un algorithme spécifique. Une classe externe, appelée directeur, contrôle l'algorithme de construction.

Échantillon

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace ConsoleApp_Design_Patterns
{

    class BuilderDesignPattern
    {
        static void Main(string[] args)
        {
            //create a constructor object to start building
            Kid aKid = new Kid();
            aKid.Name = "Elizabeth";

            //Elizabeth use Monkey mold to make a monkey
            Console.WriteLine("{0} start making a monkey", aKid.Name);
            AnimalBuilder builderA = new MonkeyBuilder();
            aKid.MakeAnimal(builderA);
            builderA.aAnimal.ShowMe();

            //Elizabeth use Kitten mold to make a kitten
            Console.WriteLine("{0} start making a kitten", aKid.Name);
            AnimalBuilder builderB = new KittenBuilder();
            aKid.MakeAnimal(builderB);
            builderB.aAnimal.ShowMe();

            Console.Read();
        }
    }
    public abstract class AnimalBuilder
    {
        public Animal aAnimal;

        public abstract void BuildAnimalHeader();
        public abstract void BuildAnimalBody();
        public abstract void BuildAnimalLeg();
        public abstract void BuildAnimalArm();
        public abstract void BuildAnimalTail();
    }
    public class MonkeyBuilder : AnimalBuilder
    {

        public MonkeyBuilder()
        {
            aAnimal = new Monkey();
        }

        public override void BuildAnimalHeader()
        {
            aAnimal.Head = "Moneky's Head has been built";
        }

        public override void BuildAnimalBody()
        {
            aAnimal.Body = "Moneky's Body has been built";
        }

        public override void BuildAnimalLeg()
        {
            aAnimal.Leg = "Moneky's Leg has been built";
        }

        public override void BuildAnimalArm()
        {
            aAnimal.Arm = "Moneky's Arm has been built";
        }

        public override void BuildAnimalTail()
        {
            aAnimal.Tail = "Moneky's Tail has been built";
        }
    }
    public class KittenBuilder : AnimalBuilder
    {
        public KittenBuilder()
        {
            aAnimal = new Kitten();
        }

        public override void BuildAnimalHeader()
        {
            aAnimal.Head = "Kitten's Head has been built";
        }

        public override void BuildAnimalBody()
        {
            aAnimal.Body = "Kitten's Body has been built";
        }

        public override void BuildAnimalLeg()
        {
            aAnimal.Leg = "Kitten's Leg has been built";
        }

        public override void BuildAnimalArm()
        {
            aAnimal.Arm = "Kitten's Arm has been built";
        }

        public override void BuildAnimalTail()
        {
            aAnimal.Tail = "Kitten's Tail has been built";
        }
    }
    public abstract class Animal
    {
        public string Head { get; set; }
        public string Body { get; set; }
        public string Leg { get; set; }
        public string Arm { get; set; }
        public string Tail { get; set; }


        //helper method for demo the Polymorphism, so we can 
        //easily tell what type object it is from client.
        public abstract void Eat();

        //helper method for demo the result from client
        public void ShowMe()
        {
            Console.WriteLine(Head);
            Console.WriteLine(Body);
            Console.WriteLine(Leg);
            Console.WriteLine(Arm);
            Console.WriteLine(Tail);
            Eat();

        }
    }
    public class Monkey : Animal
    {
        //helper method to show monkey's property for demo purpose
        public override void Eat()
        {
            Console.WriteLine("Since I am Monkey, I like to eat banana");
        }
    }
    public class Kitten : Animal
    {
        public override void Eat()
        {
            Console.WriteLine("Since I am Kitten, I like to eat kitten food");
        }
    }
    public class Kid
    {
        public string Name { get; set; }

        //construct process to build an animal object, 
        //after this process completed, a object 
        //will be consider as a ready to use object.
        public void MakeAnimal(AnimalBuilder aAnimalBuilder)
        {
            aAnimalBuilder.BuildAnimalHeader();
            aAnimalBuilder.BuildAnimalBody();
            aAnimalBuilder.BuildAnimalLeg();
            aAnimalBuilder.BuildAnimalArm();
            aAnimalBuilder.BuildAnimalTail();
        }


    }
}

4
2018-04-20 09:06



Constructeur et Usine abstraite ont signifié à des fins différentes. Selon le cas d'utilisation approprié, vous devez sélectionner un modèle de conception approprié.

Constructeur principales caractéristiques:

  1. Le modèle Builder construit un objet complexe en utilisant des objets simples et en utilisant une approche pas à pas
  2. Une classe Builder génère l'objet final étape par étape. Ce générateur est indépendant des autres objets
  3. Remplacement à la méthode Usine / Usine abstraite dans ce scénario: Trop d'arguments à passer du programme client à la classe Usine qui peut être sujette aux erreurs
  4. Certains paramètres peuvent être facultatifs, contrairement à Factory qui force l'envoi de tous les paramètres

Usine(usine simple) caractéristiques saillantes:

  1. Modèle de création
  2. Basé sur l'héritage
  3. Factory retourne une méthode d'usine (interface) qui à son tour retourne un objet concret
  4. Vous pouvez remplacer les nouveaux objets concrets par l'interface et le client (appelant) ne doit pas connaître toutes les implémentations concrètes.
  5. Client toujours accéder à l'interface uniquement et vous pouvez masquer les détails de création d'objet dans la méthode Factory.

Souvent, les conceptions commencent à utiliser Méthode d'usine (moins compliqué, plus personnalisable, les sous-classes prolifèrent) et évoluent vers Usine abstraite, Prototype, ou Constructeur (plus flexible, plus complexe)

Jetez un oeil sur les articles connexes:

Garder le constructeur dans une classe séparée (interface fluide)

Design Patterns: Usine vs méthode d'usine vs Usine abstraite

Vous pouvez vous référer aux articles ci-dessous pour plus de détails:

sourcemaking

journaldev


4
2018-02-15 19:35