Когда бы вы использовали шаблон Builder? [закрыто]

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

Рассмотрите ресторан. Создание "сегодняшней еды" является шаблоном "фабрика", потому что Вы говорите, что кухня "получает меня, сегодняшняя еда" и кухня (фабрика) решают что объект генерировать, на основе скрытых критериев.

разработчик появляется, если Вы заказываете пользовательскую пиццу. В этом случае официант говорит шеф-повару (разработчик), "Мне нужна пицца; добавьте сыр, лук и бекон к нему!" Таким образом разработчик представляет атрибуты, которые сгенерированный объект должен иметь, но скрывает, как установить их.

Вы используете его, когда у Вас есть много опций иметь дело с. Думайте о вещах как jmock:

m.expects(once())
    .method("testMethod")
    .with(eq(1), eq(2))
    .returns("someResponse");

Это чувствует себя намного более естественным и... возможно.

существует также xml здание, строковое здание и много других вещей. Вообразите, поместил ли java.util.Map как разработчик. Вы могли сделать материал как это:

Map<String, Integer> m = new HashMap<String, Integer>()
    .put("a", 1)
    .put("b", 2)
    .put("c", 3);

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

мы могли использовать фабрику вместо этого? Да

, Почему не сделал нас? Разработчик имеет больше смысла, который я предполагаю.

Фабрики используются для создания различных типов объектов, которые являются тем же основным типом (реализуйте тот же интерфейсный или базовый класс).

Разработчики создают тот же тип объекта много раз, но конструкция является динамичной, таким образом, это может быть изменено во времени выполнения.

Основываясь на предыдущих ответах (предназначенная игра слов), превосходный реальный пример Groovy, созданный в поддержке Builders.

• Создание XML использование Groovy MarkupBuilder
• Создание XML использование Groovy StreamingMarkupBuilder
• Разработчик Swing
• SwingXBuilder

См. Разработчики в Документация Groovy

. СЕТЕВОЙ класс StringBuilder является ярким примером шаблона разработчика. Это главным образом используется для создания строки в серии шагов. Конечным результатом Вы входите в выполнение ToString () всегда является строка, но создание той строки варьируется согласно тому, какие функции в классе StringBuilder использовались. Таким образом, основная идея состоит в том, чтобы создать сложные объекты и скрыть детали реализации того, как она создается.

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

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

Кроме того, существует множество разновидностей построителя. Наемник-камикадзе дает еще один.

Ниже приведены некоторые аргументы в пользу использования шаблона и примера кода на Java, но это реализация шаблона сборщика, охваченная Gang of Four в Design Patterns. Причины, по которым вы бы использовали его в Java, также применимы и к другим языкам программирования.

Как утверждает Джошуа Блох в Effective Java, 2-я редакция :

Шаблон конструктора является хорошим выбором при проектировании классов, конструкторы или статические фабрики которых имели бы более чем горстку параметров.

В какой-то момент мы все столкнулись с классом со списком конструкторов, в котором каждое добавление добавляет новый параметр опции:

Pizza(int size) { ... }        
Pizza(int size, boolean cheese) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon) { ... }

Это называется Telescoping Constructor Pattern (Телескопическая модель конструктора). Проблема с этой моделью заключается в том, что когда длина конструкторов составляет 4 или 5 параметров, становится трудно запомнить требуемый порядок параметров , а также какой конкретный конструктор вы можете захотеть в данной ситуации.

Pizza pizza = new Pizza(12);
pizza.setCheese(true);
pizza.setPepperoni(true);
pizza.setBacon(true);

public class Pizza {
  private int size;
  private boolean cheese;
  private boolean pepperoni;
  private boolean bacon;

  public static class Builder {
    //required
    private final int size;

    //optional
    private boolean cheese = false;
    private boolean pepperoni = false;
    private boolean bacon = false;

    public Builder(int size) {
      this.size = size;
    }

    public Builder cheese(boolean value) {
      cheese = value;
      return this;
    }

    public Builder pepperoni(boolean value) {
      pepperoni = value;
      return this;
    }

    public Builder bacon(boolean value) {
      bacon = value;
      return this;
    }

    public Pizza build() {
      return new Pizza(this);
    }
  }

  private Pizza(Builder builder) {
    size = builder.size;
    cheese = builder.cheese;
    pepperoni = builder.pepperoni;
    bacon = builder.bacon;
  }
}

Pizza pizza = new Pizza.Builder(12)
                       .cheese(true)
                       .pepperoni(true)
                       .bacon(true)
                       .build();