В чем разница между шаблоном проектирования Builder и шаблоном дизайна Factory?
Какой из них более выгоден и почему?
Как представить свои результаты в виде графика, если я хочу проверить и сравнить/сопоставить эти шаблоны?
В чем разница между шаблоном проектирования Builder и шаблоном дизайна Factory?
Какой из них более выгоден и почему?
Как представить свои результаты в виде графика, если я хочу проверить и сравнить/сопоставить эти шаблоны?
С шаблонами проектирования обычно нет "более выгодного" решения, которое работает для всех случаев. Это зависит от того, что вам нужно реализовать.
Из Википедии:
- Builder фокусируется на построении сложный объект шаг за шагом. Абстрактные Factory подчеркивается семейство продуктов объекты (простые или сложные). Builder возвращает продукт как окончательный шаг, но в отношении абстрактного Factory, продукт получает немедленно возвращается.
- Builder часто создает Composite.
- Часто дизайн начинается с использования метода Factory (менее сложный, более настраиваемые, подклассы размножаются) и развиваться в направлении Abstract Factory, Prototype или Builder (более гибкий, более сложный) в качестве дизайнера обнаруживает, где больше гибкости необходимо.
- Иногда шаблоны создания дополняют друг друга: Builder может использовать один других моделей для реализации какие компоненты будут построены. Абстрактные Factory, Builder и Prototype могут использовать Singleton в своих реализации.
Запись в Википедии для шаблона дизайна Factory: http://en.wikipedia.org/wiki/Factory_method_pattern
Запись в Википедии для шаблона проектирования строителя: http://en.wikipedia.org/wiki/Builder_pattern
Фабрика - это просто функция-обертка вокруг конструктора (возможно, в другом классе). Основное отличие состоит в том, что шаблон фабричного метода требует, чтобы весь объект был построен за один вызов метода, а все параметры передаются в одной строке. Конечный объект будет возвращен.
Шаблон построителя, с другой стороны, по сути является объектом-оболочкой для всех возможных параметров, которые вы, возможно, захотите передать в вызов конструктора. Это позволяет вам использовать методы установки для медленного построения списка параметров. Еще одним дополнительным методом в классе построителя является метод build(), который просто передает объект построителя в нужный конструктор и возвращает результат.
В статических языках, таких как Java, это становится более важным, когда у вас есть более, чем несколько (потенциально необязательных) параметров, поскольку это устраняет необходимость иметь телескопические конструкторы для всех возможных комбинаций параметров. Кроме того, конструктор позволяет использовать методы установки для определения доступных только для чтения или закрытых полей, которые нельзя изменить напрямую после вызова конструктора.
Базовый заводской пример
// 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");
Пример Basic Builder
// 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
Шаблон Factory можно рассматривать почти как упрощенную версию шаблона Builder.
В шаблоне Factory Factory отвечает за создание различных подтипов объекта в зависимости от потребностей.
Пользователь метода Factory не должен знать точный подтип этого объекта. Пример метода Factory createCar
может возвращать типизированный объект Ford
или Honda
.
В шаблоне Builder различные подтипы также создаются методом построения, но состав объектов может отличаться в пределах одного и того же подкласса.
Чтобы продолжить пример автомобиля, у вас может быть метод createCar
builder, который создает объект Honda
с 4-цилиндровым двигателем или объект Honda
с 6 цилиндрами. Шаблон построителя допускает эту более тонкую детализацию.
Диаграммы шаблона Builder и Factory шаблон метода доступны в Википедии.
Шаблон проектирования строителя описывает объект, который знает, как создать другой объект определенного типа за несколько шагов. Он удерживает необходимое состояние для целевого элемента на каждом промежуточном этапе. Подумайте, что делает StringBuilder для создания окончательной строки.
Шаблон проектирования factory описывает объект, который знает, как создать несколько разных, но связанных видов объектов за один шаг, где выбран конкретный тип на основе заданных параметров. Подумайте о системе сериализации, где вы создаете свой сериализатор, и он конструирует желаемый объект в одном вызове нагрузки.
Поэтапное построение сложного объекта: шаблон построителя
Простой объект создается с помощью одного метода: factory шаблон метода
Создание объекта с помощью нескольких методов factory: Абстрактный factory шаблон
Шаблон Builder и Factory, оба выглядят очень похожими на невооруженные глаза, потому что они оба создают объекты для вас.
Этот реальный пример прояснит разницу между ними.
Предположим, вы пошли в ресторан быстрого питания и заказали еду.
Пицца
Стручковый перец, помидор, курица-барбекю, НЕТ ананаса
Таким образом, различные виды продуктов изготавливаются по шаблону Фабрики, но различные варианты (вкусы) конкретного продукта создаются по шаблону Builder.
Разные виды пищи
Пицца, бургер, паста
Варианты пиццы
Только сыр, сыр + помидор + стручковый перец, сыр + помидор и т.д.
Вы можете увидеть пример реализации кода обоих шаблонов здесь
Образец строителя
Фабричный образец
Оба являются шаблонами Creation для создания Object.
1) Factory Образец. Предположим, у вас есть один суперкласс и 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 и т.д.). Через некоторое время какой-то разработчик признал, что если они следуют этим принципам, есть некоторые аналогичные решения, которые хорошо работали с аналогичными проблемами. Эти стандартные решения оказались шаблонами проектирования.
Таким образом, шаблоны проектирования помогут вам следовать общим принципам проектирования, чтобы достичь слабосвязанных систем с высокой степенью сцепления.
Отвечая на вопрос:
Задавая разницу между двумя шаблонами, вы должны спросить себя, какой шаблон делает вашу систему более гибкой. Каждый шаблон имеет свою собственную цель для организации зависимостей между классами в вашей системе.
Абстрактный Factory Образец: GoF: "Предоставьте интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов".
Что это значит: Предоставляя такой интерфейс, вызов конструктора каждого из продуктов familys инкапсулируется в класс Factory. И поскольку это единственное место во всей вашей системе, где вызывается эти конструкторы, вы можете изменить свою систему, внедряя новый класс Factory. Если вы обменяете представление Factory на другое, вы можете обменивать весь набор продуктов, не касаясь большей части вашего кода.
Шаблон Builder: GoF: "Отделить построение сложного объекта от его представления, чтобы тот же процесс построения мог создавать разные представления".
Что это значит: Вы инкапсулируете процесс строительства в другой класс, называемый режиссером (GoF). Этот директор содержит алгоритм создания новых экземпляров продукта (например, составьте сложный продукт из других частей). Чтобы создать неотъемлемые части всего продукта, режиссер использует строителя. Обменивая строителя на директора, вы можете использовать тот же алгоритм для создания продукта, но изменить представления отдельных частей (и, следовательно, представление продукта). Чтобы расширить или изменить вашу систему в представлении продукта, вам нужно всего лишь реализовать новый класс строителя.
Короче говоря: Цель Abstract Factory Patterns - обмен набором продуктов, которые используются вместе. Цель шаблонов Builder заключается в инкапсуляции абстрактного алгоритма создания продукта для повторного использования его для разных представлений продукта.
По-моему, вы не можете сказать, что абстрактный шаблон Factory является большим братом шаблона 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 |
+-------------------------------------------------------------------+---------------------------------------------------+
Шаблон телескопического конструктора
Аналогия:
Одна поразительная разница между 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();
}
Здесь во втором случае, даже если одна операция завершится неудачно, вы все равно получите автомобиль.
Может быть, автомобиль не работает отлично позже, но у вас будет объект.
Потому что метод factory дает вам автомобиль в одном вызове, тогда как Builder строит один за другим.
Хотя, это зависит от потребностей соизволения, к которому нужно идти.
Builder и Abstract Factory предназначены для разных целей. В зависимости от правильного варианта использования вы должны выбрать подходящий шаблон дизайна.
Основные особенности Builder:
Factory (простые Factory) основные особенности:
Часто проекты начинаются с использования метода Factory (менее сложные, настраиваемые, подклассы размножаются) и развиваются в направлении Abstract Factory, Prototype или Builder (более гибкие, более сложные)
Посмотрите похожие сообщения:
Сохранение строителя в отдельном классе (свободный интерфейс)
Шаблоны проектирования: Factory vs Factory метод против Аннотация Factory
Более подробную информацию можно найти в следующих статьях:
Это шаблон создания, который используется для управления созданием экземпляра класса. Шаблон построителя используется для создания сложных объектов с составными частями, которые должны быть созданы в том же порядке или с использованием определенного алгоритма. Внешний класс, известный как директор, управляет алгоритмом построения.
Пример
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 Head has been built";
}
public override void BuildAnimalBody()
{
aAnimal.Body = "Moneky Body has been built";
}
public override void BuildAnimalLeg()
{
aAnimal.Leg = "Moneky Leg has been built";
}
public override void BuildAnimalArm()
{
aAnimal.Arm = "Moneky Arm has been built";
}
public override void BuildAnimalTail()
{
aAnimal.Tail = "Moneky Tail has been built";
}
}
public class KittenBuilder : AnimalBuilder
{
public KittenBuilder()
{
aAnimal = new Kitten();
}
public override void BuildAnimalHeader()
{
aAnimal.Head = "Kitten Head has been built";
}
public override void BuildAnimalBody()
{
aAnimal.Body = "Kitten Body has been built";
}
public override void BuildAnimalLeg()
{
aAnimal.Leg = "Kitten Leg has been built";
}
public override void BuildAnimalArm()
{
aAnimal.Arm = "Kitten Arm has been built";
}
public override void BuildAnimalTail()
{
aAnimal.Tail = "Kitten 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 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();
}
}
}
Фабрика: используется для создания экземпляра объекта, где зависимости объекта полностью хранятся на фабрике. Для шаблона абстрактной фабрики часто существует много конкретных реализаций одной и той же абстрактной фабрики. Правильная реализация фабрики вводится через внедрение зависимостей.
Строитель: Используется для создания неизменяемых объектов, когда зависимости объекта, который должен быть создан, частично известны заранее и частично предоставлены клиентом строителя.
Абстрактный шаблон Factory и Builder - это оба шаблона Creational, но с разными намерениями.
Аннотация Factory Шаблон подчеркивает создание объекта для семейств связанных объектов, где:
Шаблон Builder фокусируется на построении сложного объекта шаг за шагом. Он отделяет представление от процесса построения сложного объекта, так что один и тот же процесс построения может использоваться для разных представлений.
Я считаю, что использование и разница между Factory & Шаблоны построителя можно легче понять/уточнить за определенный период времени, поскольку вы работали над одной и той же кодовой базой и меняли требования.
По моему опыту, обычно вы начинаете с паттерна Factory, включающего несколько статических методов-создателей, которые в первую очередь скрывают относительно сложную логику инициализации. Поскольку ваша иерархия объектов становится более сложной (или когда вы добавляете больше типов, параметров), вы, вероятно, в конечном итоге заполняете ваши методы большим количеством параметров, и не говоря уже о том, что вам придется перекомпилировать модуль Factory. Все эти вещи увеличивают сложность методов вашего создателя, снижают читаемость и делают модуль создания более хрупким.
Эта точка, возможно, будет точкой перехода/расширения. Тем самым вы создадите модуль-обертку вокруг параметров конструкции, а затем сможете представлять новые (похожие) объекты, добавляя еще несколько абстракций (возможно) и реализации, не затрагивая фактическую логику создания. Итак, у вас была "менее" сложная логика.
Честно говоря, ссылка на что-то вроде "создание объекта за один шаг или несколько шагов - это различие", так как единственного фактора разнообразия мне было недостаточно, чтобы различать их, поскольку я мог использовать оба способа почти во всех случаях, с которыми я сталкивался до сейчас, не испытывая никакой пользы. Так вот что я наконец-то подумала об этом.
Сложная конструкция - это когда конструируемый объект состоит из других объектов, которые представлены абстракциями.
Рассмотрим меню в McDonald's. Меню содержит напиток, основное и боковое. В зависимости от того, какие потомки отдельных абстракций составлены вместе, созданное меню может иметь другое представление.
Там мы получили два экземпляра меню с разными представлениями. Процесс строительства в свою очередь остается прежним. Вы создаете меню с напитком, основным и боковым.
Используя шаблон построителя, вы отделяете алгоритм создания сложного объекта от различных компонентов, использованных для его создания.
С точки зрения шаблона компоновщика алгоритм инкапсулируется в директоре, тогда как компоновщики используются для создания составных частей. Изменение используемого компоновщика в алгоритме директора приводит к другому представлению, потому что другие части составляются в меню. Способ создания меню остается прежним.
Разница очевидна В шаблоне строителя строитель создаст для вас определенный тип объекта. Вы должны сказать, что строитель должен построить. В шаблоне factory, используя абстрактный класс, вы напрямую строите конкретный объект.
Здесь класс строителя действует как посредник между основным классом и конкретными типами классов. Больше абстракции.
Оба очень похожи, но если у вас есть большое количество параметров для создания объекта, причем некоторые из них необязательны с некоторыми значениями по умолчанию, перейдите к шаблону Builder.
Оба шаблона имеют одну и ту же необходимость: скрыть от некоторого клиентского кода логику построения сложного объекта. Но что делает "сложным" (или иногда усложняющим) объект? Главным образом, это связано с зависимостями, а точнее состоянием объекта, состоящего из более частичных состояний. Вы можете ввести зависимости с помощью конструктора, чтобы установить начальное состояние объекта, но объекту может потребоваться много из них, некоторые будут в исходном состоянии по умолчанию (просто потому, что мы должны были узнать, что установка зависимости по умолчанию на ноль - не самый чистый способ ) и некоторый другой набор в состояние, управляемое некоторым условием. Кроме того, существуют свойства объекта, которые являются своего рода "забывчивыми зависимостями", но также они могут принимать необязательные состояния.
Есть два хорошо известных способа справиться с этой сложностью:
Композиция/агрегация: создайте объект, создайте его зависимые объекты, затем соедините вместе. Здесь конструктор может сделать прозрачным и гибким процесс, который определяет правила, определяющие конструкцию компонента.
Полиморфизм: правила построения объявляются непосредственно в определении подтипа, поэтому у вас есть набор правил для каждого подтипа, и некоторые условия решают, какое из этих правил применимо для построения объекта. Завод идеально подходит для этого сценария.
Ничто не мешает смешать эти два подхода. Семейство продуктов может абстрагироваться от создания объекта, выполненного с помощью компоновщика, а компоновщик может использовать фабрики для определения того, какой компонент объекта создается.
ИМХО
Builder - это нечто более сложное Factory.
Но в Builder вы можете создавать объекты с использованием других фабрик, которые необходимы для создания окончательного и допустимого объекта.
Итак, говоря об эволюции "Создание шаблонов" по сложности, вы можете думать об этом следующим образом:
Dependency Injection Container -> Service Locator -> Builder -> Factory
Основное различие между ними заключается в том, что шаблон Builder в основном описывает пошаговое создание сложных объектов. В шаблоне Абстрактная фабрика акцент делается на семействах объектов-продуктов. Builder возвращает продукт на последнем шаге. Находясь в шаблоне Абстрактная фабрика, продукт доступен сразу.
Пример: Допустим, мы создаем лабиринт
1. Абстрактная фабрика:
Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* maze = factory.MakeMaze(); /// product is available at start!!
/* Call some methods on maze */
return maze;
}
2. Строитель:
Maze* MazeGame::CreateMaze (MazeBuilder& builder) {
builder.buildMaze(); /// We don't have access to maze
/* Call some methods on builder */
return builder.GetMaze();
}
Абстрактный factory похож на конструктор, поскольку он также может создавать сложные объекты. Основное различие заключается в том, что шаблон Builder фокусируется на построении сложного объекта шаг за шагом. Акцент акцентирован на семействах объектов продукта (простых или сложных).
Строитель и абстрактная фабрика
Шаблон проектирования Builder в некоторой степени очень похож на шаблон Abstract Factory. Вот почему так важно иметь возможность различать ситуации, когда используется один или другой. В случае абстрактной фабрики клиент использует фабричные методы для создания своих собственных объектов. В случае Builder класс Builder получает инструкции о том, как создать объект, а затем его запрашивают, но способ, которым этот класс составлен, зависит от класса Builder, и эта деталь делает различие между двумя шаблонами.
Общий интерфейс для продуктов
На практике продукты, созданные бетоностроителями, имеют существенно различную структуру, поэтому, если нет причин выводить разные продукты, общий родительский класс. Это также отличает шаблон Builder от шаблона Abstract Factory, который создает объекты, производные от общего типа.
Строка рисунка подчеркивает сложность создания объекта (решается "шагами" )
Абстрактный шаблон подчеркивает "просто" на "абстракции" (нескольких, но связанных) объектов.
По моему мнению Шаблон Builder используется, когда вы хотите создать объект из группы других объектов, а создание части должно быть независимым от объекта, который вы хотите создать. Это помогает скрыть создание части от клиента, чтобы сделать построитель и клиент независимым. Он используется для создания сложных объектов (объекты, которые могут состоять из сложных свойств)
В то время как шаблон factory указывает, что вы хотите создать объекты общего семейства, и вы хотите, чтобы это было сразу. Он используется для более простых объектов.
Пример
1) с использованием абстрактного factory:
GUIFactory factory = new WindowsGUIFactory();
Button button = factory.createButton(); // **creates a WindowsButton**
2) с помощью построителя:
GUIBuilder builder = new WindowsGUIBuilder();
Button button = builder.createButton(); // **creates a Button.**
button.setOS = OSEnum.Windows;
Поскольку не существует класса WindowsButton, он (строитель) должен отвечать за правильное построение кнопки, то есть: button.setOS = windows
.
Это похоже на сравнение TPH vs TPT в дизайне db.
Factory pattern создает конкретную реализацию класса во время выполнения, т.е. его основная цель заключается в использовании полиморфизма, чтобы позволить подклассам решать, какой класс следует создавать. Это означает, что во время компиляции мы не знаем точный класс, который будет создан, в то время как шаблон Builder в основном касается решения проблемы антивибрации конструкторов телескопов, что возникает из-за большого количества необязательных полей класса. В шаблоне построителя нет понятия полиморфизма, поскольку мы знаем, какой объект мы пытаемся построить во время компиляции.
Единственной распространенной темой этих двух шаблонов является скрытие конструкторов и создание объектов по методам factory и метод сборки для улучшения построения объекта.
Factory шаблон позволяет создавать объект сразу, а шаблон-строитель позволяет разбить процесс создания объекта. Таким образом, вы можете добавлять различные функции во время создания объекта.