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

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

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

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

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

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

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

шаблон строителя, С другой стороны, по сути является объектом-оболочкой вокруг всех возможных параметров, которые вы можете передать в вызов конструктора. Это позволяет использовать методы 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 для создания конечной строки.

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

• построение сложного объекта шаг за шагом: шаблон builder

• простой объект создается с помощью одного метода: шаблон Заводского метода

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

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

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

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

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: "предоставьте интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов."

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

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

что это значит: Вы инкапсулируете процесс построения в другой класс, называемый director (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);
  }

но что, если при создании мест произойдет какое-то исключение ??? ВЫ НЕ ПОЛУЧИТЕ ОБЪЕКТ // Но!--5-->

предположим, у вас есть реализация как следующее

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


    }
}

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

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

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

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

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

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

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

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

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

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

sourcemaking

journaldev

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

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

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

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

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

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

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

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

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

1) Какая Еда?

пицца

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

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

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

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

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

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

только сыр, Сыр + Помидор + стручковый перец, сыр+помидор и т. д.

код образец

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

оба очень похожи, но если у вас есть большое количество параметров для создания объекта с некоторыми из них необязательно с некоторыми значениями по умолчанию, перейдите к шаблону 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, эта деталь делает разницу между двумя шаблонами.

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

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

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

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

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

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

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

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

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

ИМХО

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

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

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

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

шаблон фабрики создает конкретную реализацию класса во время выполнения, i.e его основная цель-использовать полиморфизм,чтобы подклассы могли решать, какой класс создавать. Это означает, что во время компиляции мы не знаем точный класс, который будет создан, в то время как шаблон 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 в дизайне БД.