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

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

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

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

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

Изменить с помощью диаграммы последовательности UML для Builder из GoF:

Ответ 1

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

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

Ответ 2

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

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

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

Я хотел бы подчеркнуть, что Fluent Interfaces не просто Цепочка методов. Это распространенное заблуждение. Метод 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 и Закон Деметры. Но поскольку это фасад поверх кода, который, надеюсь, следует этим принципам дизайна, это не имеет большого значения, поскольку вы локализуете нарушения в Fluent Interface.