Модель строителя: не можем ли мы упростить создание объекта строителя? - PullRequest
Новая
       73

Модель строителя: не можем ли мы упростить создание объекта строителя?

0 голосов
/ 04 мая 2020

Просто обдумываю шаблон Builder, и у меня есть несколько (нуб) вопросов. В основном, почему мы не можем просто упростить создание объекта-строителя?

Вместо этого: 

public final class Foo {

    private final String name;
    private final String description;

    private Foo(String name, String description) {
        this.name = name;
        this.description = description;
    }

    public String getName() {
        return name;
    }

    public String getDescription() {
        return description;
    }

    public static class Builder {
        private String name;
        private String description;

        public Builder setName(String name) {
            this.name = name;
            return this;
        }

        public Builder setDescription(String description) {
            this.description = description;
            return this;
        }

        public Foo build() {
            return new Foo(name, description);
        }

    }

}

//Use it
Foo f = new Foo.Builder().setName("test").setDescription("description").build();

Почему бы просто не использовать это? 

public final class Foo {

    private String name;
    private String description;

    public String getName() {
        return name;
    }

    public String getDescription() {
        return description;
    } 

    public Foo setName(String name){
       this.name=name;
       return this; 
    }

    public Foo setDescription(String description){
       this.description=description;
       return this; 
    }
}

//Use it
Foo f = new Foo().setName("test").set("description");

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

Ответы [ 3 ]

1 голос
/ 04 мая 2020

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

Foo f = new Foo (). SetDescription ("description");

Это означает, что мы java создали объект в вашей системе без имени.
Если мы возьмем другой пример, который будет самоочевидным.

Employee emp = new Employee () .setDescription ("manager");

Это означает, что я нанял менеджера в компании даже без имени.

В основном с помощью Build () мы можем также сделать обязательно все необходимые переменные-члены предоставляются при создании объекта. Мы можем даже сделать бази c проверки, если это необходимо. 

public Foo build() {
                if(name == null){
                    throw Exception();
                else
                    return new Foo(name, description);
}
1 голос
/ 04 мая 2020

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

Да, это наиболее очевидно для построения неизменяемых объектов, но он также применяется очень часто, когда только некоторые аспекты объекта являются неизменными. Типичными примерами являются:

  • Часто идентификатор объекта (например, имя человека) указывается во время построения, но после этого не может изменяться;
  • Внедренные зависимости, подобно используемой базе данных, используемому журналу и т. д. c. часто не разрешается изменять после построения;
  • Фабрикам и стратегиям часто не разрешается изменяться после построения, поскольку объект ожидает согласованности по всему все их выходы.

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

0 голосов
/ 04 мая 2020

Ваш путь - «Шаблоны JavaBeans», начиная с effectice java item2 ： Конструкция «Шаблоны JavaBean» разделена на несколько вызовов, JavaBean может находиться в несовместимом состоянии частично через его строительство. Класс не имеет возможности обеспечения согласованности, просто проверяя правильность параметров конструктора. Попытка использовать объект, когда он находится в несогласованном состоянии, может привести к сбоям, которые далеко удалены от кода, содержащего ошибку, и, следовательно, трудны для отладки. Связанный недостаток заключается в том, что шаблон JavaBeans исключает возможность сделать класс неизменным и требует дополнительных усилий со стороны программиста для обеспечения безопасности потоков. «Шаблон строителя» является поточно-ориентированным и более читабельным.

вы можете использовать аннотацию lombok @Builder для создания класса «Шаблон строителя».

...