Где бы вы использовали паттерн-строитель вместо абстрактной фабрики?

AbstractFactory предназначен для семейства сопутствующих продуктов. Строитель рассчитан на одно изделие.

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

Примеры того, что означает разница для вызывающего кода:

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

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

ОБНОВЛЕНО в ответ на этот комментарий:

Lino> Но меня это все равно беспокоит :). Я имею в виду, что если вы строите составные объекты и убираете директора, передавая ответственность за вызов методов построителя клиентам, то это работает для меня. Только тогда строитель будет казаться идеально подходящим. Но с режиссером это не похоже ...

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

Если вам нужно несколько раз повторно использовать сложный процесс сборки, у вас может быть метод для его инкапсуляции (и этот метод является вашим «руководителем»).

Напротив, для AbstractFactory обычно требуется многоразовый директор, который создает похожие продукты (предоставляется с реализацией Factory).

Здесь уже есть несколько очень хороших ответов. Я просто предлагаю аналогию.

Допустим, вам нужен новый стол для нового офиса. Вы идете на «фабрику» и видите выбранные товары, а затем выбираете одну из полок. Если это соответствует вашим потребностям, отлично!

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

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

Ладно, глупая история, но просто для облегчения: P

Хороший пример, когда вам нужен конструктор, - это создание чего-то по частям на основе аргументов командной строки. Например, рассмотрим конструктор с такими методами, как ...

setName()
setType()
setOption()

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

Иногда эстетика одного рисунка лучше подходит, чем эстетика другого.

Builder полезен для настройки. Абстрактная фабрика полезна, когда вы не хотите, чтобы вызывающие абоненты заботились о фактической реализации. Две разные цели.

Фактически, вы можете смешивать эти два паттерна. Например, DocumentBuilderFactory в Java является классическая абстрактная фабрика: если вы прочитаете документацию, вы увидите процесс, который она использует для выбора реализации. Однако DocumentBuilder, он производит, может быть настроен позже (хотя они не следуют прототипному подходу «построителя», когда каждый метод конфигурации возвращает настраиваемый объект).

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

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

Я думаю, что вы могли бы использовать и то, и другое одновременно, с абстрактной фабрикой, действующей в качестве директора в шаблоне Строителя, и каждой конкретной фабрикой, управляющей вещами по-разному. Однако это выходит за рамки «салфетки» для диаграмм UML ;-)

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

Я не уверен, что это правильное использование, но именно так я видел это и как делал это в прошлом.

Рассмотрим аналогию.

Вы работаете в сети ресторанов быстрого питания, где на самом деле они довольно сложны. Это не только сложно, но только определенные люди могут принять ваш заказ на определенные виды еды. Вы этого не знаете, потому что менеджер магазина решил посадить одного человека за одну кассу. Но если вы внимательно посмотрите на него, то на самом деле это продвинутая голограмма, потому что она «абстрактная». Абстрактный заказчик. Теперь, когда вы разговариваете с голограммой и размещаете заказ, компьютер с голограммой перенаправляет (полиморфизм) этот заказ на имплант в мозг человека, принимающего заказы. Имплант заставляет человека действительно пробивать в реальном регистре. Немногие из этих "конкретных" человеческих существ с управляемым разумом, которым приказывает голограмма. Теперь, когда настоящий человек вводит заказ, его отправляют на компьютер сзади, где есть сборочная линия или «строитель» для каждого типа создаваемой еды. Заказы отправляются на разные конвейеры в зависимости от человека и его кассового аппарата.

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

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

Для получения дополнительной информации о когда использовать шаблон Builder и его преимуществах ознакомьтесь с моим сообщением по другому аналогичному вопросу здесь

На практике вы, вероятно, будете использовать DI + IOC, чтобы делать то, что раньше делал конструктор. К вашему сведению.

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

Если у вас новый офис и вам нужны только новые столы, вы можете использовать Builder. Письменный стол всегда будет письменным столом, но существует множество различных конфигураций стола: размер, форма, наличие ящика, ящиков и т. Д.

Если у вас новый офис, а внутри полностью пусто, вам понадобятся различные предметы и вы бы использовали абстрактную фабрику, которая создает мебель, из которой происходит наш стол. В этом случае Desk, как мы знаем, является «сложным» объектом, поэтому он использует шаблон Builder, но здесь он является частью управляющей абстрактной фабрики. Абстрактная фабрика также может создавать простые объекты, такие как очень специфические лампы (StraightFunkyLamp), через класс StraightFunkyLampFactory.