Builder Pattern: Зачем нам нужно .build()?

Question

При исследовании шаблон строитель, стандартный шаблон, как:

new SandwichBuilder().salami().pastrami().cat().build(); 

Где .salami(), .pastrami(), and .cat() возвращения SandwichBuilders и .build() возвращает Sandwich.

---

Считается ли плохой стиль вместо этого использовать следующее соглашение?

new Sandwich().salami().pastrami().cat(); 

Где .salami(), .pastrami(), and .cat() возвращение Sandwich непосредственно предшествующее, казалось бы, ненужное усложнение?

Answer 1

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

JB Nizet указывает на то, что Guava's Splitter, что является хорошим примером последнего случая. По вашему мнению, разработчики Guava, должно быть, чувствовали, что «предшествовавшее, казалось бы, ненужное осложнение» было достаточным основанием для терпения нескольких дополнительных копий во время создания настраиваемых Splitter.

Answer 2

Последний не совсем плохой стиль, но требует, чтобы объект можно было использовать сразу, а затем добавить к одному атрибуту за раз.

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

В примере сэндвич последний, вероятно, прекрасен, и нет необходимости в отдельном классе строителя. Возможно, элемент управления GUI хочет сначала собрать все параметры, а затем сделать одно время, а не воссоздавать/обновлять для каждого отдельного параметра, и в этом случае более подходящим будет отдельный Builder.