Шаблон строителя: почему директор строит объект?

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

Один из лучших способов взглянуть на Builder — это слияние шаблонного метода и фабрики: нам нужен абстрактный процесс построения, чтобы мы могли поддерживать создание различных продуктов, но процесс построения включает много шагов. Идея состоит в том, что когда у вас есть архитектура Director/Builder, вы можете легко добавлять новые Builders, предоставляя новую конкретную реализацию. Это похоже на шаблонный метод, потому что Builder также может игнорировать детали семантики конструкции и просто предоставлять реализации каждой необходимой части конструкции (обратите внимание также, что некоторая логика может оказаться в абстрактной базе иерархии Builder, еще больше расширяя количество автоматических функций, которые более поздние расширители получают бесплатно).

Назначение класса Director — инкапсулировать алгоритм создания объекта, т.е. отделить код логики построения от кода тех частей, которые собственно составляют объект. Без класса Director ваш класс Builder был бы более громоздким и менее модульным, поэтому его было бы сложнее поддерживать и использовать повторно.

пример из Википедии, на который вы ссылаетесь, довольно упрощен. Со сложными объектами механизм построения обычно намного сложнее, и директор не обязательно вызывает методы Builder один за другим и в том порядке, в котором они определены. Рассмотрим, например, класс Cake: он может иметь части ChocolateLayer, CreamLayer и Strawberry. Builder определяет три метода для создания этих трех частей в этом конкретном порядке, однако метод constructCake() в вашем классе Director может выглядеть примерно так:

public void constructCake() {
   CakeBuilder.createNewCakeProduct(); 
   CakeBuilder.buildChocolateLayer(); 
   CakeBuilder.buildCreamLayer(); 
   CakeBuilder.buildChocolateLayer(); // 2nd call of the same Builder method
   int totalStrawberries = 3 + new Random().nextInt(2);
   for (int i = 1; i <= totalStrawberries; i++) 
      CakeBuilder.buildStrawberry(); // put some strawberries on top
   // Please don't try this recipe at home! 
}

Что касается различий между Builder и Decorator, вы можете проверить шаблон Builder Vs Decorator< /а> вопрос.

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

class Waiter {
    private PizzaBuilder pizzaBuilder;

    public void setPizzaBuilder(PizzaBuilder pb) { pizzaBuilder = pb; }
    public Pizza getPizza() { return pizzaBuilder.getPizza(); }

    public void constructPizza() {
        pizzaBuilder.createNewPizzaProduct();
        pizzaBuilder.buildDough();
        pizzaBuilder.buildSauce();
        pizzaBuilder.buildTopping();
    }
}

Обратите внимание, что Waiter работает только с PizzaBuilder, он не знает, SpicyPizzaBuilder это или HawaiianPizzaBuilder, и это цель этого шаблона. В этом другом фрагменте кода:

class BuilderExample {
    public static void main(String[] args) {
        Waiter waiter = new Waiter();
        PizzaBuilder hawaiianPizzaBuilder = new HawaiianPizzaBuilder();
        PizzaBuilder spicyPizzaBuilder = new SpicyPizzaBuilder();

        waiter.setPizzaBuilder( hawaiianPizzaBuilder );
        waiter.constructPizza();

        Pizza pizza = waiter.getPizza();

        waiter.setPizzaBuilder( spicyPizzaBuilder );
        waiter.constructPizza();

        Pizza anotherPizza = waiter.getPizza();
    }
}

вы можете увидеть, как это работает. Создается Waiter и передается сначала HawaiianPizzaBuilder, а затем SpicyPizzaBuilder, и с тем же экземпляром Waiter вы можете создать пиццу и попросить ее, и он доставит правильную. Надеюсь, я объяснил себя и что этот комментарий поможет вам ;) Удачи!!!

Мое объяснение шаблона Builder: давайте предположим, что у нас есть объект (продукт) и для создания объекта требуется много параметров или компонентов (других объектов), теперь, что еще хуже, не все эти параметры могут потребоваться, поэтому это приведет нам либо создать много конструкторов с разными параметрами, либо ввести множество логических операторов внутри единственного конструктора, чтобы выбрать этот и отклонить этот объект, и, что еще хуже, возможно, что эти компоненты должны быть построены по порядку (в определенной последовательности) или выполните некоторую проверку бизнес-правил для них, все это сводится к сложному конструктору, который тесно связан с параметрами (компонентами) и сложен в обслуживании. Решение состоит в том, чтобы переместить эту логику в конкретный конструктор, чтобы мы получили наш объект, вызвав ConcreteBuilder.BuildComponent1(), ConcreteBuilder.BuildComponent2(), ..., ConcreteBuilder.GetMeMyObject(), но это будет тесно связано с клиентским кодом в процессе построения, каждый клиент теперь полностью осведомлен обо всех шагах, необходимых для создания нашего любимого объекта, поэтому любое изменение в процессе построения заставит нас изменить весь код клиента здесь и там, чтобы решить эту проблему, шаблон Builder вводит Director, который инкапсулирует эти шаги, и теперь все клиенты вызывают метод Build() в Режиссер, чтобы создать объект. Подводя итог, директор существует, поэтому клиентский код не знает или не тесно связан с шагами, необходимыми для создания нашего любимого объекта, теперь для чего нужны эти BuildComponent1(), BuildComponent2() методы, ну они там для решения проблем конструктора Для этого существует шаблон, о котором я упоминал в начале: теперь мы можем обеспечить порядок в процессе построения компонента, мы также можем применить бизнес-логику, уникальную для каждого конкретного конструктора внутри этих методов, мы даже можем оставить реализацию пустой для некоторые конкретные строители, потому что просто наш конечный объект (Продукт) не нуждается в этом компоненте, и теперь мы инкапсулировали этот сложный процесс построения вдали от нашего любимого объекта, который делает свою работу лучше всего, не беспокоясь о том, как построить его самостоятельно.