El patrón de fábrica casi se puede ver como una versión simplificada del patrón del constructor.

En el patrón Factory, la fábrica se encarga de crear varios subtipos de un objeto dependiendo de las necesidades.

El usuario de un método factory no necesita saber el subtipo exacto de ese objeto. Un ejemplo de un método de fábrica createCar podría devolver un objeto escrito Ford o Honda.

En el patrón Builder , diferentes subtipos también son creados por un método builder, pero la composición de los objetos puede diferir dentro de la misma subclase.

Para continuar con el ejemplo de car, es posible que tenga un método de constructor createCar que crea un objeto con tipo Honda con un motor de 4 cilindros, o un objeto con tipo Honda con 6 cilindros. El patrón del constructor permite esta granularidad más fina.

Los diagramas de Patrón Constructory el Patrón método fábrica están disponibles en Wikipedia.

Una factory es simplemente una función de envoltura alrededor de un constructor (posiblemente uno en una clase diferente). La diferencia clave es que un patrón de método de fábrica requiere que todo el objeto se construya en una sola llamada al método, con todos los parámetros que pasan en una sola línea. El objeto final será devuelto.

Un patrón de constructor, por otro lado, es en esencia un objeto de envoltura alrededor de todos los parámetros posibles que podría querer pasar a una invocación de constructor. Este le permite usar métodos de configuración para construir lentamente su lista de parámetros. Un método adicional en una clase builder es un método build (), que simplemente pasa el objeto builder al constructor deseado y devuelve el resultado.

En lenguajes estáticos como Java, esto se vuelve más importante cuando tiene más de un puñado de parámetros (potencialmente opcionales), ya que evita el requisito de tener constructores telescópicos para todas las combinaciones posibles de parámetros. También un constructor le permite usar métodos setter para definir campos de solo lectura o privados que no se pueden modificar directamente después de haber llamado al constructor.

Ejemplo Básico de Fábrica

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

Ejemplo de constructor básico

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

Vale la pena comparar las muestras de código de estas dos páginas de wikipedia:

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

El patrón de diseño del constructor describe un objeto que sabe cómo crear otro objeto de un tipo específico en varios pasos. Mantiene el estado necesario para el elemento de destino en cada paso intermedio. Piense por lo que StringBuilder pasa para producir una cadena final.

El patrón de diseño de fábrica describe un objeto que sabe cómo crear varios tipos diferentes pero relacionados de objeto en un solo paso, donde el tipo específico se elige en función de parámetros dados. Piensa en el sistema de serialización, donde crea su serializador y construye el objeto deseado en una llamada de carga.

• Construyendo un objeto complejo paso a paso: builder pattern

• Un objeto simple se crea utilizando un único método: método de fábrica patrón

• Crear objeto usando el método de fábrica múltiple: Patrón abstracto de fábrica

Ambos son patrones de creación, para crear Objetos.

1) Patrón de fábrica-Supongamos que tiene una superclase y N número de subclases. El objeto que se crea depende del parámetro / valor que se pase.

2) Patrón de constructor-para crear objetos complejos.

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.

Primero algunas cosas generales para seguir mi argumentación:

El principal desafío en el diseño de grandes sistemas de software es que tienen que ser flexibles y sin complicaciones para cambiar. Por esta razón, hay algunas métricas como acoplamiento y cohesión. Para lograr sistemas que puedan ser fácilmente alterados o ampliados en su funcionalidad sin la necesidad de rediseñar todo el sistema desde cero, puede seguir los principios de diseño (como SOLID, etc.).). Después de un tiempo algún desarrollador reconoció que si siguen esos principios hay algunas soluciones similares que funcionaron bien a problemas similares. Esas soluciones estándar resultaron ser los patrones de diseño.

Por lo tanto, los patrones de diseño son para ayudarlo a seguir los principios generales de diseño para lograr sistemas de acoplamiento flexible con alta cohesión.

Respondiendo a la pregunta:

Al preguntar la diferencia entre dos patrones tienes que preguntarte qué patrón hace que tu sistema de qué manera más flexible. Cada patrón tiene su propio propósito para organizar dependencias entre clases en su sistema.

El Patrón Abstracto de la Fábrica: GoF: "Proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas."

¿Qué significa esto: Al proporcionar una interfaz como esta, la llamada al constructor de cada uno de los productos de la familia se encapsula en la clase factory. Y porque este es el solo coloque en todo su sistema donde se llaman esos constructores, puede alterar su sistema implementando una nueva clase de fábrica. Si cambias la representación de la fábrica a través de otra, puedes cambiar un conjunto completo de productos sin tocar la mayoría de tu código.

El Patrón del Constructor: GoF: "Separar la construcción de un objeto complejo de su representación para que el mismo proceso de construcción pueda crear diferentes representaciones."

¿Qué significa esto: Encapsulas el proceso de construcción en otra clase, llamada el director (GoF). Este director contiene el algoritmo para crear nuevas instancias del producto (por ejemplo, componer un producto complejo a partir de otras partes). Para crear las partes integrales de todo el producto, el director utiliza un constructor. Al intercambiar el constructor en el director se puede utilizar el mismo algoritmo para crear el producto, pero cambiar las representaciones de single partes (y así la representación del producto). Para ampliar o modificar su sistema en la representación del producto, todo lo que necesita hacer es implementar una nueva clase builder.

Así que en resumen: El propósito del patrón Abstracto de la Fábrica es intercambiar un conjunto de productos que se hacen para ser utilizados juntos. El propósito del Patrón del Constructor es encapsular el algoritmo abstracto de crear un producto para reutilizarlo para diferentes representaciones del producto.

En mi opinión usted no se puede decir que el Patrón Abstracto de la Fábrica es el hermano mayor del Patrón Constructor. Sí, ambos son patrones creacionales, pero la intención principal de los patrones es completamente diferente.

Una diferencia sorprendente entre Builder & factory que pude distinguir fue la siguiente

Supongamos que tenemos un coche

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

En la interfaz anterior podemos obtener el coche de la siguiente manera:

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

Pero ¿qué pasa si ocurre alguna excepción al crear los Asientos ??? NO OBTENDRÁ EL OBJETO EN ABSOLUTO // PERO

Supongamos que tiene una implementación como la siguiente

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

Ahora puedes crear así

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

  }

Aquí en el segundo caso, incluso si una operación falla y aun así conseguirías el auto.

Puede ser que el coche no funciona perfectamente más tarde, pero, usted tendría el objeto.

Porque el Método de fábrica le da el coche en una sola llamada , mientras que el Constructor construye uno por uno.

Aunque, depende de las necesidades de los dignatarios a cuál ir.

Este es un patrón de creación, ya que se utiliza para controlar la instanciación de clases. El patrón de constructor se utiliza para crear objetos complejos con partes constituyentes que deben crearse en el mismo orden o utilizando un algoritmo específico. Una clase externa, conocida como el director, controla el algoritmo de construcción.

Muestra

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


    }
}

Builder y Abstract Factory han significado para diferentes propósitos. Dependiendo del caso de uso correcto, debe seleccionar el patrón de diseño adecuado.

Constructor características destacadas:

1. Builder pattern construye un objeto complejo usando objetos simples y usando un enfoque paso a paso
2. Una clase Builder construye el objeto final paso a paso. Este constructor es independiente de otros objetos
3. Reemplazo al método de fábrica / Fábrica abstracta en este escenario: Demasiados argumentos para pasar del programa cliente a la clase de fábrica que pueden ser propensos a errores
4. Algunos de los parámetros pueden ser opcionales, a diferencia de Factory, que obliga a enviar todos los parámetros

Fábrica (fábrica simple) características destacadas:

1. Patrón de creación
2. Basado en la herencia
3. Factory devuelve un Método de Fábrica (interfaz) que a su vez devuelve Objeto Concreto
4. puede sustituir el Hormigón nuevo Los objetos para interfaz y cliente (llamante) no deben ser conscientes de todas las implementaciones concretas
5. El cliente siempre accede solo a la interfaz y puede ocultar los detalles de creación de objetos en el método Factory.

A menudo, los diseños comienzan usando Método de fábrica (menos complicado, más personalizable, proliferan subclases) y evolucionan hacia Fábrica abstracta, Prototipo , o Constructor (más flexible, más complejo)

Echa un vistazo a los relacionados mensajes:

Mantener el constructor en una clase separada (interfaz fluida)

Patrones de diseño: Fábrica vs método de fábrica vs Fábrica Abstracta

Puede consultar los siguientes artículos para obtener más detalles:

Creación de fuentes

Journaldev

Los patrones abstractos de fábrica y constructor son patrones de creación pero con diferentes intenciones.

Abstract Factory Pattern enfatiza la creación de objetos para familias de objetos relacionados donde:

• Cada familia es un conjunto de clases derivadas de una clase/Interfaz base común.
• Cada objeto se devuelve inmediatamente como resultado de una llamada.

Builder pattern se centra en construir un objeto complejo paso a paso. Desacopla el representación del proceso de construcción del objeto complejo, de modo que el mismo proceso de construcción puede ser utilizado para diferentes representaciones.

• El objeto Builder encapsula la configuración del objeto complejo.
• El objeto Director conoce el protocolo de usar el Constructor, donde protocol define todos los pasos lógicos necesarios para construir el objeto complejo.

Patrón de constructor y patrón de fábrica, ambos parecen bastante similares a los ojos desnudos porque ambos crean objetos para usted.

Pero tienes que mirar más de cerca

Este ejemplo de la vida real hará la diferencia entre los dos más clara.

Supongamos que fuiste a un restaurante de comida rápida y ordenaste Comida.

1) ¿Qué Alimento?

Pizza

2) ¿Qué coberturas?

Pimiento, Tomate, pollo a la BARBACOA, NO PIÑA

Así que los diferentes tipos de alimentos se hacen por patrón de fábrica, pero las diferentes variantes(sabores) de un alimento en particular se hacen por patrón de constructor.

Diferentes tipos de alimentos

Pizza, Hamburguesa, Pasta

Variantes de Pizza

Solo Queso, Queso + Tomate + Pimiento, Queso+Tomate, etc.

Ejemplo de código

Puede ver la implementación de código de ejemplo de ambos patrones aquí
Constructor Patrón
Patrón De Fábrica

Ambos son muy similares , pero si tiene un gran número de parámetros para la creación de objetos con algunos de ellos opcionales con algunos valores predeterminados , vaya a Builder pattern.

+-------------------------------------------------------------------+---------------------------------------------------+
|                              Builder                              |                      Factory                      |
+-------------------------------------------------------------------+---------------------------------------------------+
| Return only single instance to handle complex object construction | Retrun various instances on multiple constructors |
| No interface required                                             | Interface driven                                  |
| Inner classes is involved (to avoid telescopic constructors)      | Subclasses are involved                           |
+-------------------------------------------------------------------+---------------------------------------------------+  

Patrón de construcción telescópico

Analogía:

• Fábrica: Considere un restaurante. La creación de "la comida de hoy" es un patrón de fábrica, porque le dices a la cocina "consígueme la comida de hoy" y la cocina (fábrica) decide qué objeto generar, basado en criterios ocultos.
• Constructor: El constructor aparece si pides una pizza personalizada. En este caso, el camarero le dice al chef (constructor) " Necesito una pizza; añadir ¡queso, cebollas y tocino!"Por lo tanto, el constructor expone los atributos que el objeto generado debería tener, pero oculta cómo configurarlos.

Cortesía

Una construcción compleja es cuando el objeto a construir está compuesto de otros objetos diferentes que están representados por abstracciones.

Considere un menú en McDonalds. Un menú contiene una bebida, un plato principal y un acompañante. Dependiendo de qué descendientes de las abstracciones individuales se componen juntas, el menú creado tiene otra representación.

1. Ejemplo: Cola, Big Mac, Papas fritas
2. Ejemplo: Sprite, Nuggets, Rizado Fries

Ahí tenemos dos instancias del menú con diferentes representaciones. El proceso de construcción a su vez sigue siendo el mismo. Usted crea un menú con una bebida, un principal y un lado.

Al usar el patrón de constructor, se separa el algoritmo de creación de un objeto complejo de los diferentes componentes utilizados para crearlo.

En términos del patrón de constructor el algoritmo está encapsulado en el director, mientras que los constructores se utilizan para crear las partes integrales. Variando el constructor utilizado en el algoritmo de el director resulta en una representación diferente porque otras partes se componen a un menú. La forma en que se crea un menú sigue siendo la misma.

El patrón de compilación enfatiza la complejidad de crear el objeto (resuelto por "pasos")

El patrón abstracto enfatiza "solo" en la "abstracción" de objetos (múltiples pero relacionados).

La diferencia es clara En patrón de constructor, constructor creará un tipo específico de objeto para usted. Tienes que decir qué el constructor tiene que construir. En patrón de fábrica, usando clase abstracta usted está construyendo directamente el objeto específico.

Aquí la clase builder actúa como mediador entre la clase principal y las clases de tipo específicas. Más abstracción.

Creo que el uso y la diferencia entre los patrones de Fábrica y Constructor se pueden entender/aclarar más fácilmente en un cierto período de tiempo a medida que se trabaja en la misma base de código y los requisitos cambiantes.

Desde mi experiencia, por lo general, se comienza con un patrón de fábrica que incluye un par de métodos creadores estáticos. A medida que su jerarquía de objetos se vuelve más compleja (o a medida que agrega más tipos), probablemente termine con sus métodos poblados con más parámetros y sin mencionar usted tendrás que recompilar tu módulo de fábrica. Todas esas cosas, aumenta la complejidad de sus métodos de creador, disminuye la legibilidad y hace que el módulo de creación sea más frágil.

Este punto posiblemente será el punto de transición. Transición de fábrica a patrón Constructor. Al hacerlo, crea un módulo de envoltura alrededor de los parámetros de construcción y luego podrá representar nuevos objetos (similares) agregando algunas abstracciones e implementaciones más(tal vez) sin tocar real su lógica de creación. Así que has tenido una lógica menos compleja y el código fuente recompilado

Francamente, hacer referencia a algo como "tener un objeto creado en un solo paso o varios pasos es la diferencia", ya que el único factor de diversidad no era suficiente para distinguirlos, ya que podía usar ambas formas para casi todos los casos que enfrenté hasta ahora sin experimentar ningún beneficio. Así que esto es lo que finalmente he pensado.

Abstract factory es similar a builder en que también puede construir objetos complejos. La principal diferencia es que el patrón Builder se centra en construir un objeto complejo paso a paso. El énfasis de Abstract factor está en las familias de objetos de producto (simples o complejos).

Constructor y Fábrica Abstracta

El patrón de diseño del constructor es muy similar, en cierta medida, al patrón de Fábrica abstracto. Es por eso que es importante ser capaz de hacer la diferencia entre las situaciones cuando se utiliza una u otra. En el caso de la Fábrica Abstracta, el cliente utiliza los métodos de la fábrica para crear sus propios objetos. En el caso del Constructor, la clase Builder recibe instrucciones sobre cómo crear el objeto y luego se le pregunta por él, pero la forma en que la clase es poner juntos depende de la clase Constructor, este detalle hace la diferencia entre los dos patrones.

Interfaz común para productos

En la práctica, los productos creados por los constructores de hormigón tienen una estructura significativamente diferente, por lo que si no hay una razón para derivar diferentes productos, una clase matriz común. Esto también distingue el patrón Constructor del patrón de Fábrica abstracto que crea objetos derivados de un tipo común.

Desde: http://www.oodesign.com/builder-pattern.html

En mi opinión Builder pattern se utiliza cuando desea crear un objeto a partir de un grupo de otros objetos y la creación de la parte debe ser independiente del objeto que desea crear. Ayuda a ocultar la creación de la parte del cliente para hacer constructor y cliente independiente. Se utiliza para la creación de objetos complejos (objetos que pueden consistir en propiedades complicadas)

Mientras que el patrón de fábrica especifica que desea crear objetos de una familia común y desea que sea cerated a la vez. Se utiliza para objetos más simples.

Ambos patrones vienen por la misma necesidad: Ocultar de algún código cliente la lógica de construcción de un objeto complejo...pero, ¿qué hace que un objeto sea" complejo " (o, a veces, complicado)? Principalmente, se debe a dependencias, o más bien al estado de un objeto compuesto por estados más parciales. Puede inyectar dependencias por constructor para establecer el estado inicial del objeto, pero un objeto puede requerir muchas de ellas, algunas estarán en un estado inicial predeterminado (solo porque deberíamos haber aprendido que establecer un estado predeterminado dependecy a null no es la forma más limpia) y algún otro conjunto a un estado impulsado por alguna condición. Además, hay propiedades de objetos que son algún tipo de "dependencias ajenas", pero también pueden asumir estados opcionales

Hay dos formas bien conocidas de dominar esa complejidad:

• composition / aggregation: Construye un objeto, construye sus objetos dependientes, luego conecta juntos. Aquí un constructor puede hacer transparente y flexible el proceso que determina las reglas que conducen la construcción del componente
• Polimorfismo: Las reglas de construcción se declaran directamente en la definición de subtipos, por lo que tiene un conjunto de reglas para cada subtipo y alguna condición decide cuál de estos conjuntos de reglas se aplica para construir el objeto. Una fábrica encaja perfectamente en este escenario

Nada impide mezclar estos dos enfoques. Una familia de productos podría abstraer la creación de objetos hecha con un constructor, un constructor podría usar fábricas para determinar qué componente objeto de crear instancias de

EN MI HUMILDE opinión

Builder es una especie de Fábrica más compleja.

Pero en Builder puedes crear instancias de objetos usando otras factories, que son necesarias para construir el objeto final y válido.

Así que, hablando de la evolución de los "Patrones Creacionales" por complejidad, puedes pensarlo de esta manera:

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

El patrón de fábrica crea una implementación concreta de una clase en tiempo de ejecución, es decir, su intención principal es usar polimorfismo para permitir que las subclases decidan qué clase instanciar. Esto significa que en tiempo de compilación no sabemos la clase exacta que se creará, mientras que Builder pattern se ocupa principalmente de resolver el problema de telescoping constructors antipattern, que surge debido a un gran número de campos opcionales de una clase. En patrón constructor no hay noción de polimorfismo, como sabemos qué objeto estamos tratando de construir en tiempo de compilación.

El único tema común de estos dos patrones es la ocultación de los constructores y la creación de objetos detrás de los métodos de fábrica, y el método build, para mejorar la construcción de objetos.

El patrón de fábrica le permite crear un objeto a la vez, mientras que el patrón de constructor le permite romper el proceso de creación de un objeto. De esta manera, puede agregar diferentes funcionalidades durante la creación de un objeto.

Un ejemplo

1) usando abstract factory:

GUIFactory factory = new WindowsGUIFactory();
Button button = factory.createButton(); // **creates a WindowsButton**

2) usando builder:

GUIBuilder builder = new WindowsGUIBuilder();
Button button = builder.createButton(); // **creates a Button.** 
button.setOS = OSEnum.Windows;

Como no hay clase WindowsButton, él (el constructor) debe estar a cargo de construir correctamente el botón, es decir: button.setOS = windows.

Es similar a comparar TPH vs TPT en el diseño de la base de datos.