Заводской шаблон можно почти рассматривать как упрощенную версию шаблона Builder.

на завод узор, фабрика отвечает за создание различных подтипов объекта в зависимости от потребностей.

пользователю Заводского метода не нужно знать точный подтип этого объекта. Пример фабричного метода createCar может вернуть a Ford или Honda типизированный объект.

на Строитель шаблон, различные подтипы создаются методом строитель, но состав объектов может отличаться в пределах одного подкласса.

чтобы продолжить пример автомобиля, у вас может быть createCar builder метод, который создает Honda - типизированный объект с 4-цилиндровым двигателем, или Honda-типизированный объект с 6 цилиндрами. Шаблон builder позволяет получить более тонкую детализацию.

схемы как шаблона и метод фабрики шаблон доступны в Википедии.

завод - это просто обертка вокруг функции конструктора (возможно, в другом классе). Ключевое различие заключается в том, что шаблон метода фабрики требует, чтобы весь объект был построен в одном вызове метода, причем все параметры передаются в одной строке. Окончательный объект будет возвращен.

шаблон строителя, С другой стороны, по сути является объектом обертки вокруг всех возможных параметров, которые вы можете захотеть передать в a вызов конструктора. Это позволяет использовать методы setter для медленного создания списка параметров. Одним из дополнительных методов в классе builder является метод build (), который просто передает объект builder в нужный конструктор и возвращает результат.

в статических языках, таких как 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();

возможно, стоит сравнить примеры кода из этих двух Википедии страницы:

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

шаблон проектирования builder описывает объект, который знает, как создать другой объект определенного типа за несколько шагов. Он содержит необходимое состояние для целевого элемента на каждом промежуточном шаге. Подумайте, что StringBuilder проходит для получения конечной строки.

шаблон проектирования фабрики описывает объект, который знает, как создать несколько различных, но связанных видов объектов за один шаг, где конкретный тип выбирается на основе заданных параметров. Думаю система сериализации, где вы создаете свой сериализатор и он создает нужный объект в одном вызове загрузки.

• строительство сложного объекта шаг за шагом : шаблон строителя

• простой объект создается с помощью одного метода: factory method pattern

• создание объекта с помощью метода нескольких фабрик: абстрактный заводской шаблон

оба являются творческими шаблонами, чтобы создать объект.

1) Заводской шаблон-Предположим, у вас есть один суперкласс и N количество подклассов. Объект создается в зависимости от того, какой параметр/значение передается.

2) Builder pattern-для создания сложного объекта.

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.

во-первых, некоторые общие вещи, чтобы следовать моей аргументации:

основная проблема при проектировании больших программных систем заключается в том, что они должны быть гибкими и несложными для изменения. По этой причине существуют некоторые показатели, такие как сцепление и сцепление. Для достижения систем, которые могут быть легко изменены или расширены в своей функциональности без необходимости перепроектировать всю систему с нуля, вы можете следовать принципам проектирования (например, SOLID и т. д.). Через некоторое время разработчик признал, что если они следуют этим принципам, есть некоторые аналогичные решения, которые хорошо работают с аналогичными проблемами. Эти стандартные решения оказались образцами дизайна.

таким образом, шаблоны проектирования должны поддерживать вас, чтобы следовать общим принципам проектирования для достижения слабосвязанных систем с высокой когезией.

отвечая на вопрос:

задавая разницу между двумя шаблонами, вы должны спросить сам какой шаблон делает вашу систему более гибкой. Каждый шаблон имеет свою собственную цель для организации зависимостей между классами в вашей системе.

Абстрактный Заводской Шаблон: GoF: "предоставьте интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов."

что это значит: Предоставляя такой интерфейс, вызовите конструктор каждого продукта семейства инкапсулируется в Заводском классе. И поскольку это единственное место во всей вашей системе, где называются эти конструкторы, вы можете изменить свою систему, реализовав новый класс фабрики. Если вы обмениваете представление фабрики через другое, вы можете обменять целый набор продуктов, не касаясь большинства вашего кода.

Шаблон Построителя: Гоф: "отделите построение сложного объекта от его представления так, чтобы то же самое процесс строительства может создавать различные представления."

что это значит: Вы инкапсулируете процесс построения в другой класс, называемый директором (GoF). Этот директор содержит алгоритм создания новых экземпляров продукта (например, составить сложный продукт из других частей). Для создания составных частей всего продукта директор использует конструктор. Обменяв конструктор в директоре, вы можете использовать тот же алгоритм для создания продукт, но изменить представления отдельных частей (и поэтому представление продукта). Чтобы расширить или изменить вашу систему в представлении продукта, все, что вам нужно сделать, это реализовать новый класс builder.

короче: Абстрактная Фабричная модель предназначена для обмена набором продуктов, которые сделаны для совместного использования. Цель шаблона Builder-инкапсулировать абстрактный алгоритм создания продукта для его повторного использования различные представления продукта.

на мой взгляд, вы не можете сказать, что абстрактный Заводской шаблон является старшим братом шаблона Builder. Да, они оба являются творческими паттернами, но основная цель паттернов совершенно различна.

одно поразительное различие между Builder & factory, которое я мог разобрать, было следующим

предположим, у нас есть автомобиль

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

  }

здесь во втором случае, даже если одна операция не удастся, вы все равно получите автомобиль.

может быть , что автомобиль не работает отлично позже, но, вы бы объект.

потому что заводской метод дает вам автомобиль в одном вызове, в то время как строитель строит один за другим.

хотя, это зависит от потребностей соизволил, какой из них идти.

это шаблон создания, поскольку он используется для управления экземпляром класса. Шаблон Builder используется для создания сложных объектов с составными частями, которые должны быть созданы в том же порядке или с использованием специального алгоритма. Внешний класс, известный как директор, управляет алгоритмом построения.

пример

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


    }
}

Строитель и Абстрактная Фабрика предназначены для различных целей. В зависимости от правильного варианта использования, вы должны выбрать подходящий шаблон дизайна.

Строитель отличительные особенности:

1. Builder pattern строит сложный объект, используя простые объекты и используя пошаговый подход
2. класс Builder строит конечный объект шаг за шагом. Этот строитель не зависит от других объекты
3. замена на Заводской метод / абстрактная фабрика в этом сценарии: слишком много аргументов для передачи из клиентской программы в заводской класс, который может быть подвержен ошибкам
4. некоторые параметры могут быть необязательными в отличие от фабрики, которая заставляет отправлять все параметры

завод (простая Фабрика) характерные особенности:

1. Creational pattern
2. на основе наследования
3. завод возвращает Заводской метод (интерфейс), который в свою очередь возвращает конкретный объект
4. вы можете заменить новые конкретные объекты для интерфейса и клиент (вызывающий) не должен быть в курсе всех конкретных реализаций
5. клиент всегда имеет доступ только к интерфейсу, и вы можете скрыть детали создания объекта в Заводском методе.

часто проекты начинаются с использования Метод Фабрики (менее сложные, более настраиваемые, подклассы размножаются) и развиваются навстречу Абстрактная Фабрика,прототип или Строитель (более гибкий, более сложный)

посмотрите на связанные сообщения:

сохранение builder в отдельном классе (Свободный интерфейс)

шаблоны проектирования: завод против Заводского метода против абстрактной фабрики

вы можете обратиться к ниже статьи подробности:

sourcemaking

journaldev

абстрактный шаблон фабрики и строителя - это оба творческих шаблона, но с разными намерениями.

Абстрактный Узор Завод подчеркивает создание объектов для семейств связанных объектов, где:

• каждое семейство представляет собой набор классов, производных от общего базового класса / интерфейса.
• каждый объект возвращается немедленно в результате одного вызова.

шаблона фокусируется на построении комплекса объект шаг за шагом. Он отделяет представление от процесса построения сложного объекта, так что один и тот же процесс построения может быть использован для различных представлений.

• объект Builder инкапсулирует конфигурацию сложного объекта.
• директор объекта знает протокол использования строителя, где протокол определяет все логические шаги, необходимые для построения сложных объектов.

Builder Pattern и Factory pattern, оба кажутся довольно похожими на невооруженные глаза, потому что они оба создают объекты для вас.

но вы должны смотреть ближе

этот реальный пример сделает разницу между двумя более ясными.

Предположим, вы пошли в ресторан быстрого питания и заказали еда.

1) Какая Еда?

пицца

2) какие начинки?

паприкой, Помидор, курица барбекю, нет ананас

таким образом, различные виды продуктов производятся по Заводскому шаблону, но различные варианты(ароматы) конкретной пищи производятся по шаблону строителя.

различные виды продуктов

Пицца, Гамбургер, Макаронные Изделия

варианты пиццы

только сыр, Сыр + Помидор+паприка, сыр+помидор и т. д.

код образец

вы можете увидеть пример реализации кода обоих шаблонов здесь
Шаблона
Шаблон Фабрики

оба очень похожи , но если у вас есть большое количество параметров для создания объекта с некоторыми из них необязательно с некоторыми значениями по умолчанию, перейдите к шаблону Builder.

+-------------------------------------------------------------------+---------------------------------------------------+
|                              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                           |
+-------------------------------------------------------------------+---------------------------------------------------+  

Телескопический Шаблон Конструктора

аналогия:

• Фабрика: рассмотреть ресторан. Создание "today's meal" является фабричным шаблоном, потому что вы говорите кухне "get me today's meal", и кухня (фабрика) решает, какой объект генерировать, основываясь на скрытых критериях.
• Строитель: строитель появляется, если вы заказать пиццу. В данном случае официант говорит шеф-повару (строителю): "мне нужна пицца; добавьте к ней сыр, лук и бекон!"Таким образом, строитель предоставляет атрибуты, которые должен иметь сгенерированный объект, но скрывает, как их установить.

вежливость

сложная конструкция-это когда объект, который должен быть построен, состоит из различных других объектов, которые представлены абстракциями.

рассмотрим меню в McDonalds. Меню содержит напиток, основной и побочный. В зависимости от того, какие потомки отдельных абстракций составлены вместе, созданное меню имеет другое представление.

1. Пример: Кола, Биг Мак, Картофель Фри
2. Пример: Спрайт, Самородки, Фигурные Фри

там мы получили два экземпляра меню с разными представлениями. Процесс строительства, в свою очередь, остается неизменным. Вы создаете меню с напитком, основным и боковым.

с помощью шаблона builder вы отделяете алгоритм создания сложного объекта от различных компонентов, используемых для его создания.

с точки зрения шаблона алгоритм инкапсулируется в то время как строители используются для создания неотъемлемая часть. Изменение используемого конструктора в алгоритме директора приводит к другому представлению, потому что другие части составлены в меню. Способ создания меню остается прежним.

построить шаблон подчеркивает на сложности создания объекта (решается с помощью "шагов")

абстрактный шаблон подчеркивает "просто" на "абстракции" (нескольких, но связанных) объектов.

разница понятна В шаблоне builder builder создаст для вас определенный тип объекта. Вы должны сказать, что строитель должен строить. В шаблоне фабрики, используя абстрактный класс, вы непосредственно создаете конкретный объект.

здесь класс builder выступает в качестве посредника между основным классом и конкретными классами типов. Больше абстракции.

Я считаю, что использование и разница между шаблонами Factory & Builder могут быть поняты/уточнены легче в определенный период времени, когда вы работали над одной и той же базой кода и изменяли требования.

из моего опыта, как правило, вы начинаете с заводского шаблона, включая пару статических методов создателя. Поскольку ваша иерархия объектов становится более сложной (или по мере добавления новых типов), вы, вероятно, закончите тем, что ваши методы будут заполнены большим количеством параметров, а не упомяните, что вам придется перекомпилировать свой заводской модуль. Все эти вещи, увеличивает сложность ваших методов создателя, уменьшает читаемость и делает модуль создания более хрупким.

эта точка, возможно, будет точкой перехода. Переход от фабрики к шаблону строителя. Таким образом, вы создаете модуль-оболочку вокруг параметры конструкции и тогда вы сможете представлять новые (аналогичные) объекты, добавив еще несколько абстракций(возможно) и реализации, не касаясь фактической логики вашего создания. Таким образом, у вас была менее сложная логика и повторно скомпилированный исходный код

откровенно говоря, ссылаясь на что-то вроде "наличие объекта, созданного в один шаг или несколько шагов, - это разница", поскольку единственный фактор разнообразия не был достаточным для меня, чтобы различать их, поскольку я мог использовать оба способа почти для всех случаев, с которыми я сталкивался до сих пор, не испытывая никакой пользы. Так вот что я, наконец, подумал об этом.

абстрактная фабрика похожа на builder в том, что она тоже может создавать сложные объекты. Основное различие заключается в том, что шаблон Builder фокусируется на построении сложного объекта шаг за шагом. Акцент абстрактного фактора делается на семействах объектов продукта(простых или сложных).

Строитель и абстрактная Фабрика

шаблон проектирования Builder очень похож, в какой-то степени, на абстрактный Заводской шаблон. Вот почему важно уметь различать ситуации, когда используется то или иное средство. В случае абстрактной фабрики клиент использует методы фабрики для создания своих собственных объектов. В случае компоновщика класс Builder инструктируется о том, как создать объект, а затем он запрашивается для него, но способ, которым класс собран вместе до класса Builder, эта деталь делает разницу между двумя шаблонами.

общий интерфейс для продуктов

на практике продукты, созданные бетонными строителями, имеют значительно различную структуру, поэтому, если нет причин для получения разных продуктов, общий родительский класс. Это также отличает шаблон Builder от абстрактного шаблона фабрики, который создает объекты, производные от общего тип.

от:http://www.oodesign.com/builder-pattern.html

по-моему Шаблон Builder используется, когда вы хотите создать объект из множества других объектов и создания части должен быть независимым от объекта, который вы хотите создать. Это помогает скрыть создание части от клиента, чтобы сделать строителя и клиента зависит. Он используется для создания сложных объектов (объектов, которые могут состоять из сложных свойств)

в то время как шаблон фабрики указывает, что вы хотите создать объекты общего семейства, и вы хотите его для того чтобы быть аттестованным сразу. Он используется для более простых объектов.

оба шаблона приходят для одной и той же необходимости: скрыть от некоторого кода клиента логику построения сложного объекта...но что делает" сложный " (или, иногда, усложняющий) объект? В основном это связано с зависимостями, а точнее с состоянием объекта, состоящего из более частичных состояний. Вы можете вводить зависимости с помощью конструктора, чтобы установить начальное состояние объекта, но для объекта может потребоваться много их, некоторые из них будут в исходном состоянии по умолчанию (просто потому, что мы должны были узнать, что установить default dependecy to null-это не самый чистый способ) и некоторые другие устанавливаются в состояние, управляемое некоторым условием. Кроме того, есть свойства объекта, которые являются своего рода "забывчивыми зависимостями", но также они могут принимать необязательные состояния

есть два хорошо известных способа доминировать над этой сложностью:

• композиция / агрегация: построить объект, построить его зависимые объекты, а затем провод togheter. Здесь строитель может сделать процесс прозрачным и гибким это определяет правила, которые приводят к построению компонента
• полиморфизм: правила построения объявляются непосредственно в определении подтипа, поэтому у вас есть набор правил для каждого подтипа, и некоторое условие решает, какой из этих наборов правил применяется для построения объекта. Фабрика идеально вписывается в этот сценарий

ничто не мешает смешивать эти два подхода. Семейство продуктов может создавать абстрактные объекты с помощью конструктора, строителя можно использовать фабрики, чтобы определить, какой компонентный объект instantiate

ИМХО

Builder-это какая-то более сложная Фабрика.

но в Builder вы можете создавать экземпляры объектов с помощью других фабрик, которые необходимы для построения окончательного и действительного объекта.

Итак, говоря об эволюции" творческих паттернов " по сложности, вы можете думать об этом следующим образом:

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

шаблон фабрики создает конкретную реализацию класса во время выполнения, т. е. его основное намерение состоит в том, чтобы использовать полиморфизм, чтобы позволить подклассам решить, какой класс создать экземпляр. Это означает, что во время компиляции мы не знаем точный класс, который будет создан, в то время как шаблон Builder в основном связан с решением проблемы телескопирования конструкторов antipattern, которая возникает из-за большого количества необязательных полей класса. В шаблоне builder нет понятия полиморфизма, так как мы знать, какой объект мы пытаемся построить во время компиляции.

единственной общей темой этих двух шаблонов является скрытие конструкторов и создание объектов за заводскими методами и методом сборки для улучшения конструкции объекта.

Заводской шаблон позволяет создать объект сразу сразу, а шаблон builder позволяет прервать процесс создания объекта. Таким образом, вы можете добавить различные функциональные возможности во время создания объекта.

пример

1) используя абстрактную фабрику:

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

2) с помощью builder:

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

поскольку нет класса WindowsButton, он (строитель) должен отвечать за правильное построение кнопки, т. е.: button.setOS = windows.

Это похоже на сравнение TPH против TPT в дизайне db.