Является ли этот Monster Builder хорошим шаблоном Builder/Factory для абстрагирования длинных конструкторов, смешанных с сеттерами?

Ответ 1

статический внутренний строитель, прославленный josh bloch в эффективной java.

Обязательные параметры - конструкторы args, необязательные - методы.

Пример. Вызов, в котором требуется только имя пользователя:

RegisterUserDto myDto = RegisterUserDto.Builder(myUsername).password(mypassword).email(myemail).Build();

И базовый код (опуская очевидные экземпляры vars):

private RegisterUserDTO(final Builder builder) {
        super();
        this.username = builder.username;
        this.firstName = builder.firstName;
        this.surname = builder.surname;
        this.password = builder.password;
        this.confirmPassword = builder.confirmPassword;
    }


    public static class Builder {
        private final String username;

        private String firstName;

        private String surname;

        private String password;

        private String confirmPassword;

        public Builder(final String username) {
            super();
            this.username = username;
        }

        public Builder firstname(final String firstName) {
            this.firstName = firstName;
            return this;
        }

        public Builder surname(final String surname) {
            this.surname = surname;
            return this;
        }

        public Builder password(final String password) {
            this.password = password;
            return this;
        }

        public Builder confirmPassword(final String confirmPassword) {
            this.confirmPassword = confirmPassword;
            return this;
        }

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

Ответ 2

Таким образом, статический внутренний строитель в сочетании с функцией factory может выполнять некоторые из необходимых действий. (1) Он может применять зависимости типа, если установлен A, а также B. (2) Он может возвращать разные классы. (3) Он может выполнять логическую проверку записей.

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

Возможным преимуществом является шаблон "несколько строителей". Если клиент заранее знает, почему он создает конкретный элемент, тогда он может получить другой строитель. Вы можете создать конструктор для каждой комбинации.

В зависимости от типа логических зависимостей в вашем классе вы можете объединить эти несколько разработчиков с одним общим застройщиком. Вы можете иметь, скажем, общий строитель, и когда вы вызываете setOption (A) в общем построителе, он возвращает другой класс строителя, к которому вы можете только привязать методы, которые по-прежнему актуальны. Таким образом, вы получаете свободное владение, но вы можете исключить некоторые пути. Когда вы это делаете, вы должны быть осторожны, чтобы аннулировать поля, которые были установлены, но стали неуместными - вы не можете сделать подструктуры строителей друг другом.

Это может заставить клиента выбрать во время компиляции, как построить объект, это то, что вы после?

UPDATE - попытался ответить на комментарии:

Итак, сначала сначала - функция factory является первой в Joshua Blocks Эффективная Java, это просто означает, что для объекта вы делаете его конструктором частным, а вместо этого выполняете статическую функцию factory. Это более гибко, чем конструктор, потому что он может возвращать разные типы объектов. Когда вы объединяете функцию factory с несколькими сборщиками, вы можете получить очень мощную комбинацию. Вот описание шаблона: http://en.wikipedia.org/wiki/Factory_method_pattern http://en.wikipedia.org/wiki/Abstract_factory_pattern

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

public class outer{
    Map <Map<Class<?>, Object> jobsMap - holds a class object of the new builder class, and a prototypical isntance which can be cloned.
    outer(){
        jobsMap.add(Mechanic.class, new Mechanic());
        //add other classes to the map
    }

    public class GeneralBuilder{
    String name;
    int age;

//constructor enforces mandatory parameters.
    GeneralBuilder(String name, int age, \\other mandatory paramerters){
        //set params
    }

    public T setJob(Class<T extends AbstractJob> job){
        AbstractJob result = super.jobsMap.getValue(job).clone();
        //set General Builder parameters name, age, etc
        return (T) result;
    }
}

public MechanicBuilder extends AbstractJobs{
//specific properties
    MechanicBuilder(GeneralBuilder){
      // set age, name, other General Builder properties
    }
    //setters for specific properties return this
    public Person build(){
        //check mechanic mandatory parameters filled, else throw exception.
        return Person.factory(this);
    }
}

public abstract class AbstractJob{
    String name;
    String age;
    //setters;
}

public class Person {
//a big class with lots of options
//private constructor
    public static Person Factory(Mechanic mechanic){
        //set relevant person options
    }
}

Итак, теперь это бегло. Я создаю экземпляр внешнего и заполняю карту всеми конкретными типами заданий. Затем я могу создать из этого столько новых строителей, сколько хочу, как экземпляров внутреннего класса. Я устанавливаю параметры для общего конструктора, вызывающего .setJobs(Mechanic.class), и возвращает экземпляр механика, который имеет кучу определенных свойств, которые я теперь могу свободно использовать с помощью .setOptionA() и т.д. В конце концов я вызываю build и это вызывает статический метод factory в классе Person и передает себя. Вы возвращаетесь к классу людей.

Его большая реализация, так как вам нужно создать конкретный класс строителя для каждого "типа" объекта, который может быть представлен классом Person, но он делает API, который очень удобен для клиента. На практике, хотя у этих классов есть много вариантов, на практике может быть только несколько шаблонов, которые люди намереваются создать, а все остальное появляется только случайно.

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

interface FirstName {

     public LastName setFirstName(String name)

}
interface LastName {
    public OptionalInterface setLastName(String name)
}

interface OptionalParams {
    public OptionalParams setOptionalParam(String numberOfBananas)
    public OptionalParams setOptionalParam(int numberOfApples)
    public AlcoholLevel setAlcoholLevel() // go down to a new interface
    public MaritalStatus setMaritalStatus()

    public Person build()
}

interface AlcoholLevel {
    //mutually exclusive options hoist you back to options
    public OptionalParams setNumberOfBeers(int bottles)
    public OptionalParams setBottlesOfWine(int wine)
    public OptionalParams setShots(int shots)
    public OptionalParams isHammered()
    public OptionalParams isTeeTotal()
    public OptionalParams isTipsy()
}

interface MaritalStatus {
    public OptionalParams isUnmarried()
    //force you into a required params loop
    public HusbandFirstName hasHusband()
    public WifeFirstName hasWife()
}

Имея серию интерфейсов одного метода, вы можете в значительной степени заставить хорошее поведение на клиенте. Этот шаблон хорошо работает, например, с формированием сформированных HTTP-запросов в сетях, где требуются определенные аутентификации. Наложение интерфейсов поверх стандартной библиотеки httml направляет клиентов в правильном направлении.

Некоторая условная логика в основном слишком сложна, чтобы ее стоило. Такие вещи, как настаивать на том, что сумма параметра 1 и параметра 2 меньше, чем параметр 3, лучше всего решать, бросая исключение во время выполнения метода сборки.