Я бачив багато реалізацій шаблону Builder (головним чином на Java). Усі вони мають клас сутності (скажімо, Personклас) та клас будівельника PersonBuilder. Конструктор "укладає" різні поля та повертає a new Personіз переданими аргументами. Чому нам явно потрібен клас будівельника, а не розміщення всіх методів builder у самому Personкласі?

Наприклад:

class Person {

  private String name;
  private Integer age;

  public Person() {
  }

  Person withName(String name) {
    this.name = name;
    return this;
  }

  Person withAge(int age) {
    this.age = age;
    return this;
  }
}

Я можу просто сказати Person john = new Person().withName("John");

Чому потреба в PersonBuilderкласі?

Єдине благо, яке я бачу, - це те, що ми можемо оголосити Personполя такими final, забезпечуючи таким чином незмінність.

Це так, що ви можете бути незмінним І змоделювати названі параметри одночасно.

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

Це утримує ваші рукавиці від людини до тих пір, поки її стан не встановлено, і після встановлення не дозволить вам змінити його, але все поле чітко позначено. Ви не можете зробити це лише одним класом на Java.

Схоже, ви говорите про шаблон Josh Blochs Builder . Це не слід плутати з малюнком банди чотирьох будівельників . Це різні звірі. Вони обидва вирішують будівельні проблеми, але досить різними способами.

Звичайно, ви можете сконструювати об'єкт без використання іншого класу. Але тоді доведеться вибирати. Ви втрачаєте або можливість імітувати названі параметри мовами, які їх не мають (наприклад, Java), або ви втрачаєте можливість залишатися незмінними протягом усього життя об'єктів.

Незмінний приклад, не має імен параметрів

Person p = new Person("Arthur Dent", 42);

Тут ви будуєте все за допомогою простого конструктора. Це дозволить вам залишатися незмінними, але ви втратите моделювання названих параметрів. Це стає важко прочитати з багатьма параметрами. Комп'ютери байдуже, але людині важко.

Імітаційний приклад названого параметра з традиційними сетерами. Незмінна.

Person p = new Person();
p.name("Arthur Dent");
p.age(42);

Тут ви будуєте все за допомогою сетерів і моделюєте названі параметри, але ви більше не змінюєтесь. Кожне використання сетера змінює стан об'єкта.

Отже, ви отримаєте додавання класу - це ви можете зробити і те, і інше.

Перевірка може бути виконана в тому build()випадку, якщо помилка виконання для вікового поля, що відсутнє, вам достатньо. Ви можете оновити та застосувати те, що age()викликається помилкою компілятора. Тільки не з малюнком конструктора Josh Bloch.

Для цього вам потрібна внутрішня мова для домену (iDSL).

Це дозволяє вам вимагати, щоб вони дзвонили age()і name()перед тим, як дзвонити build(). Але ви не можете це зробити, просто повертаючись thisкожен раз. Кожна річ, яка повертається, повертає іншу річ, яка змушує вас називати наступне.

Використання може виглядати так:

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

Але це:

Person p = personBuilder
    .age(42)
    .build()
;

викликає помилку компілятора, оскільки age()діє лише для виклику того типу, який повертає name().

Ці iDSL є надзвичайно потужними (наприклад, JOOQ або Java8 Streams ) і дуже приємні у використанні, особливо якщо ви використовуєте IDE із заповненням коду, але вони досить дорого налаштовані. Я рекомендую зберегти їх для речей, на яких буде написано трохи вихідного коду.

Навіщо використовувати / надавати клас будівельника:

• Зробити незмінні предмети - вигода, яку ви вже визначили. Корисно, якщо будівництво здійснює кілька кроків. FWIW, незмінність слід вважати важливим інструментом у нашому прагненні до написання програм, що потребують ремонту, та без помилок.
• Якщо представлення кінцевого (можливо, незмінного) об’єкту виконання оптимізовано для читання та / або використання простору, але не для оновлення. Тут є хорошими прикладами String і StringBuilder. Неодноразово об'єднуючі рядки не дуже ефективні, тому StringBuilder використовує інше внутрішнє представлення, яке добре для додавання - але не настільки добре для використання місця, і не настільки добре для читання та використання, як звичайний клас String.
• Чітко відокремити побудовані об’єкти від об'єктів, що будуються. Цей підхід вимагає чіткого переходу від недобудови до спорудженого. Для споживача немає способу плутати об'єкт недобудови з побудованим об'єктом: система типів буде це виконувати. Це означає, що іноді ми можемо використовувати такий підхід для того, щоб «потрапити до ями успіху», і, робивши абстракцію для використання іншими (або самими собою) (наприклад, API або шаром), це може бути дуже добре річ.

Однією з причин було б забезпечити, щоб усі передані дані відповідали правилам бізнесу.

Ваш приклад не враховує це, але скажімо, що хтось пройшов у порожній рядку або рядку, що складається із спеціальних символів. Ви хочете зробити якусь логіку, яка базується на тому, щоб переконатися, що їх ім’я є дійсним іменем (що насправді є дуже складним завданням).

Ви можете сказати, що все у вашому класі Person, особливо якщо логіка дуже мала (наприклад, просто переконайтесь, що вік є негативним), але в міру зростання логіки є сенс відокремити.

Трохи інший кут на це від того, що я бачу в інших відповідях.

withFooПідхід тут є проблематичним , так як вони поводяться як сетера , але визначені таким чином , щоб створити враження опори класу незмінності. У Java-класах, якщо метод модифікує властивість, звичайно запускати метод із "set". Я ніколи не любив це як стандарт, але якщо ти робиш щось інше, це здивує людей, і це не добре. Є ще один спосіб, який можна підтримати незмінністю за допомогою базового API, який ви маєте тут. Наприклад:

class Person {
  private final String name;
  private final Integer age;

  private Person(String name, String age) {
    this.name = name;
    this.age = age;
  }  

  public Person() {
    this.name = null;
    this.age = null;
  }

  Person withName(String name) {
    return new Person(name, this.age);
  }

  Person withAge(int age) {
    return new Person(this.name, age);
  }
}

Це не забезпечує особливого способу запобігання неправомірним частково побудованим об'єктам, але запобігає змінам будь-яких існуючих об'єктів. Це, мабуть, нерозумно щодо подібних речей (так і JB Builder). Так, ви створите більше об'єктів, але це не так дорого, як ви могли подумати.

Ви в основному побачите такий тип підходу, який використовується з паралельними структурами даних, такими як CopyOnWriteArrayList . І це натякає на те, чому незмінність важлива. Якщо ви хочете зробити свій код безпечним, майже завжди слід враховувати незмінність. У Java кожному потоці дозволено зберігати локальний кеш змінного стану. Для того, щоб один потік побачив зміни, внесені в інші потоки, потрібно застосувати синхронізований блок або іншу функцію сумісності. Будь-яке з них додасть до коду трохи накладних витрат. Але якщо ваші змінні є остаточними, то нічого робити. Значенням завжди буде те, для чого воно було ініціалізовано, і тому всі потоки бачать одне і те ж, незалежно від того.

Ще одна причина, яка тут вже не була чітко вказана, полягає в тому, що build()метод може перевірити, що всі поля є 'полями, що містять дійсні значення (або встановлені безпосередньо, або отримані з інших значень інших полів), що, мабуть, є найбільш ймовірним режимом відмови що інакше відбудеться.

Ще одна перевага полягає в тому, що ваш Personоб’єкт в кінцевому підсумку має більш простий життєвий цикл і простий набір інваріантів. Ви знаєте, що як тільки у вас є Person p, ви маєте p.nameі дійсне p.age. Жоден з ваших методів не повинен бути розроблений для вирішення таких ситуацій, як "добре що, якщо встановлено вік, але не ім'я, або що, якщо ім'я встановлено, але не вік?" Це зменшує загальну складність класу.

Будівельник також може бути визначений для повернення інтерфейсу або абстрактного класу. Ви можете використовувати будівельник для визначення об'єкта, а конструктор може визначити, який конкретний підклас повернути, виходячи з того, які властивості встановлені, або для чого вони встановлені, наприклад.

Шаблон будівельника використовується для створення / створення об'єкта поетапно шляхом встановлення властивостей, і коли всі необхідні поля встановлені, потім повертайте кінцевий об'єкт за допомогою методу збирання. Новостворений об’єкт непорушний. Головне, що тут слід зазначити, це те, що об'єкт повертається лише тоді, коли викликається остаточний метод збірки. Це гарантує, що всі властивості встановлені на об'єкт, і, таким чином, об'єкт не знаходиться в непослідовному стані, коли він повертається класом builder.

Якщо ми не використовуємо клас builder і безпосередньо покладемо всі методи класу builder до самого класу Person, тоді нам слід спершу створити Object, а потім викликати методи встановлення на створеному об'єкті, що призведе до непослідовного стану об'єкта між створенням об'єкта та встановлення властивостей.

Таким чином, використовуючи клас будівельника (тобто якусь зовнішню сутність, крім класу Person), ми гарантуємо, що об'єкт ніколи не буде в непослідовному стані.

Повторне використання об’єкта builder

Як уже згадували інші, незмінність та перевірка ділової логіки всіх полів для перевірки об'єкта є головними причинами окремого об’єкта-будівельника.

Однак повторне використання - ще одна перевага. Якщо я хочу створити багато подібних об'єктів, я можу внести невеликі зміни до об'єкта будівельника та продовжити інстанціювання. Не потрібно відтворювати об’єкт будівельника. Таке повторне використання дозволяє будівельнику діяти як шаблон для створення багатьох незмінних об'єктів. Це невелика користь, але може бути корисною.

Насправді, ви можете мати методи будівельника на своєму класі і все одно мати незмінність. Це просто означає, що методи будівельника будуть повертати нові об'єкти, а не змінювати існуючі.

Це працює лише в тому випадку, якщо є спосіб отримати початковий (дійсний / корисний) об'єкт (наприклад, від конструктора, який встановлює всі необхідні поля, або фабричного методу, який встановлює значення за замовчуванням), а додаткові методи конструктора потім повертають модифіковані об'єкти на основі на існуючому. Ці методики для розробників повинні переконатися, що у вас не потрапляють недійсні / непослідовні об’єкти.

Звичайно, це означає, що у вас буде багато нових об’єктів, і ви не повинні цього робити, якщо ваші об’єкти дорого створювати.

Я використовував це в тестовому коді для створення відповідників Hamcrest для одного з моїх бізнес-об'єктів. Я не пам'ятаю точного коду, але він виглядав приблизно так (спрощено):

public class CustomerMatcher extends TypeSafeMatcher<Customer> {
    private final Matcher<? super String> nameMatcher;
    private final Matcher<? super LocalDate> birthdayMatcher;

    @Override
    protected boolean matchesSafely(Customer c) {
        return nameMatcher.matches(c.getName()) &&
               birthdayMatcher.matches(c.getBirthday());
    }

    private CustomerMatcher(Matcher<? super String> nameMatcher,
                            Matcher<? super LocalDate> birthdayMatcher) {
        this.nameMatcher = nameMatcher;
        this.birthdayMatcher = birthdayMatcher;
    }

    // builder methods from here on

    public static CustomerMatcher isCustomer() {
        // I could return a static instance here instead
        return new CustomerMatcher(Matchers.anything(), Matchers.anything());
    }

    public CustomerMatcher withBirthday(Matcher<? super LocalDate> birthdayMatcher) {
        return new CustomerMatcher(this.nameMatcher, birthdayMatcher);
    }

    public CustomerMatcher withName(Matcher<? super String> nameMatcher) {
        return new CustomerMatcher(nameMatcher, this.birthdayMatcher);
    }
}

Тоді я б використовував його так у своїх одиничних тестах (з відповідним статичним імпортом):

assertThat(result, is(customer().withName(startsWith("Paŭlo"))));