В чем разница между свободным интерфейсом и шаблоном Builder?

Question

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

Я понимаю концепцию плавных интерфейсов. Но шаблон строителя немного запутан. Я не могу понять использование директора в шаблоне Builder.

Могу ли я использовать шаблон Builder и Fluent Interface вместе? Если да, то как мне это сделать с Директором и конкретным строителем?

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

---

Edit с порядковым UML диаграммы Builder из GoF:

Answer 1

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

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

Answer 2

Fluent Interfacesсемантические фасады. Вы помещаете их поверх существующего кода, чтобы уменьшить синтаксический шум и более четко выразить то, что делает код на вездесущем языке. Это шаблон, используемый при создании внутреннего домена. Речь идет о читаемости.

Директор/строитель организует строительство чего-то. То есть, если вы строите машину для выпечки пиццы, Директор будет следить за тем, чтобы шаги от заказа до пиццы выполнялись в правильном порядке с правильными данными с помощью правильного строителя. Речь идет о валидации и делегировании.

Вы можете, конечно, установить Fluent Interface поверх шаблона Director/Builder, чтобы он читал больше - хорошо и подчеркивал концепцию домена (по сравнению с техническим процессом построения и делегирования). Тогда это будет Expression Builder.

Я хотел бы подчеркнуть, что Fluent Interfaces - это не только Method Chaining. Это распространенное заблуждение. Метод Chaining - это один из подходов к реализации Fluent Interface, но это не одно и то же, поскольку в нем отсутствуют семантические качества, например.это не является Свободным Интерфейсом:

SomeObject.setFoo(1).setBar(2).setBaz(3); 

Вышеупомянутое не выражает ничего о SomeObject. Это не фасад над некоторой семантической моделью. Это всего лишь несколько методов. Примером Fluent Interface может быть построитель запросов SQL, например.

SQLBuilder.select('foo').from('bar').where('foo = ?', 42).prepare(); 

Под капотом этого API лежит код для создания инструкции SQL. Он может включать в себя несколько объектов, и показанные вызовы могут очень хорошо создать объект Select, вызвать его установщик, создать объект условия и применить его к объекту Select и, наконец, вернуть объект Statement. Но все, что скрыто от нас. Это также подчеркивает еще один аспект Свободных интерфейсов: они могут нарушать SOLID и Law of Demeter. Но так как это фасад поверх кода, который, надеюсь, следует этим принципам дизайна, это не имеет большого значения, потому что вы локализуете нарушения в Fluent Interface.