Взаимодействие builder и factory method?

Question

[calculator212]

Возникла некоторая проблема с пониманием этих паттернов. Нормально ли обернуть билдер фабричным методом? Я понял, что идеологически билдер используется только для создания объектов, в целом можно добавить конечно метод DO или еще несколько, но вроде так обычно не делают, поэтому мне показалось неплохой идей использовать для обертки фабричный метод, которая обычно и используется для манипуляций разными объектами.
Идея примерно такая - есть билдер и над ним директор, билдер используется только для создания объекта и возвращает Product, который после будет использован для создания новой фабрики, внутри методам NewFactory выбирается структура в зависимости от типа Product и возвращается интерфейс Factory.
Правильная ли это идея или нет? Из плюсов, не всем объектам нужно будет реализовывать эти методы, т.к. они могут быть и не нужны из минусов лишняя прослойка и более сложное восприятие кода. Код ниже примерный.

type BuildProcess interface {
	M1() BuildProcess
	M2() BuildProcess
	M3() BuildProcess
	GetP() Product
}

type Product struct{}

type Director struct {
	builder BuildProcess
}

type Factory interface {
	f1()
	f2()
}

//удовлетворяет Factory
type factoryStruct struct{
	p Product
}

func (f factoryStruct )f1(){}
func (f factoryStruct )f2(){}

func NewFactory(p Product)Factory{}

Answer 1

[Антон Неверов]

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

Я так понимаю идея в том, чтобы создать продукт специфичный через строитель. И далее использовать его в фабрике.
Но в чём проблема изначально работать с разными типам продуктов? Неужели применение строителя настолько оправдано, что ради него вы плодите директора, ещё к нему бонусом самого строителя, а потом из одного класса пытаетесь что-то там фабрикой извлечь.

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

Comments

[calculator212]

зачем вам вообще всё это нужно.

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

Неужели применение строителя настолько оправдано, что ради него вы плодите директора

Ну в целом можно и без директора, просто более общий случай.

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

В целом у меня теоретический вопрос. Просто прикинул, что иногда было бы удобно добавлять функционал к объекту/объектам не трогая код самого объекта, жертвуя при этом лишним слоем абстракции. Условно у нас билдер, который создаёт разные объекты для подключения к серверам разного типа tcp/udp/ftp/... /... и нам нужно получить некоторые данные по сессиям ftp и udp, по остальным типам нам не нужна информация, дальше создаем фабрику с этим методом и реализуем эти методы только в 2 случаях из n. Ну соотвественно если нам понадобится udp или другой протокол, то по сути нам будет достаточно только реализовать метод, без фабрики придется вносить код в несколько мест с фабрикой скорее всего только в одно. Не говорю что это реальный пример и так будет писаться код, но мне кажется, что это возможный кейс, что создали библиотеку с ограниченным функционалом внутрь которой не хочется лезть и приходится писать свою надстройку, опять же не факт что это способ подойдет, я просто хотел узнать жизнеспособный он или нет.