---

🟢 Junior Level

Builder (Строитель) — это порождающий паттерн проектирования, который позволяет поэтапно создавать сложные объекты с большим количеством параметров, отделяя процесс конструирования от внутреннего представления объекта.

---

Проблемы, которые решает Builder

1. «Телескопический» конструктор (Telescoping Constructor Anti-pattern)

Когда у класса много полей, разработчики создают цепочку перегруженных конструкторов. Читать и поддерживать такой код крайне сложно, а перепутать параметры одного типа (например, несколько String подряд) очень легко:

// ❌ Антипаттерн: какой String за что отвечает?
User user = new User("Иван", "Иванов", "ivan@mail.ru", "+79991234567", "Москва", 28, true);

2. Мутабельный антипаттерн JavaBeans (сеттеры)

Создание пустого объекта с последующим вызовом сеттеров нарушает инвариант целостности:

// ❌ Опасно: объект существует в полузаполненном, невалидном состоянии!
User user = new User();
user.setFirstName("Иван");
// Если прямо сейчас другой поток прочитает user, он увидит null в lastName и email!
user.setLastName("Иванов");

---

Решение: Классический Builder

public class User {
    // Поля final обеспечивают иммутабельность (потокобезопасность)
    private final String firstName;
    private final String lastName;
    private final String email;
    private final int age;

    private User(Builder builder) {
        this.firstName = builder.firstName;
        this.lastName = builder.lastName;
        this.email = builder.email;
        this.age = builder.age;
    }

    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private String firstName;
        private String lastName;
        private String email;
        private int age;

        public Builder firstName(String firstName) {
            this.firstName = firstName;
            return this; // Fluent API
        }

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

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

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public User build() {
            // Валидация инвариантов перед созданием целевого объекта
            if (firstName == null || lastName == null) {
                throw new IllegalStateException("Имя и фамилия обязательны!");
            }
            return new User(this);
        }
    }
}

// Использование:
User user = User.builder()
    .firstName("Иван")
    .lastName("Иванов")
    .email("ivan@mail.ru")
    .age(28)
    .build();

---

Когда использовать:

• Конструктор принимает 4 и более параметров (особенно одного типа).
• У объекта много опциональных (необязательных) параметров с разумными значениями по умолчанию.
• Требуется создать иммутабельный (неизменяемый) объект со сложной валидацией инвариантов.

Когда НЕ использовать:

• У класса всего 1–3 обязательных параметра (обычный конструктор проще и быстрее).
• Простые структуры данных (Value Objects, DTO с парой полей).
• Экстремально высоконагруженные участки (hot-path), где создание промежуточных объектов-билдеров создает излишнюю нагрузку на GC.

---

🟡 Middle Level

Безопасная публикация через final поля (JMM Safe Publication)

Объект, сконструированный через Builder с final-полями, обладает гарантией безопасной публикации (Safe Publication) в соответствии с Java Memory Model (JSR-133):

• JVM гарантирует, что любой поток, получивший ссылку на объект User после завершения конструктора User(Builder), увидит корректно инициализированные значения всех final-полей без необходимости дополнительной синхронизации (volatile или synchronized).
• В отличие от подхода с сеттерами (JavaBeans), объект попадает в руки вызывающего кода только в полностью готовом и валидном виде.

---

Валидация и проверка инвариантов (Cross-Field Invariants)

Builder позволяет проводить атомарную кросс-полевую валидацию в методе build():

public class BookingRequest {
    private final LocalDate startDate;
    private final LocalDate endDate;

    private BookingRequest(Builder b) {
        this.startDate = b.startDate;
        this.endDate = b.endDate;
    }

    public static class Builder {
        private LocalDate startDate;
        private LocalDate endDate;

        public Builder startDate(LocalDate start) { this.startDate = start; return this; }
        public Builder endDate(LocalDate end) { this.endDate = end; return this; }

        public BookingRequest build() {
            if (startDate == null || endDate == null) {
                throw new IllegalArgumentException("Даты бронирования не могут быть null");
            }
            // Атомарная проверка взаимосвязанных полей
            if (startDate.isAfter(endDate)) {
                throw new IllegalStateException("Дата начала не может быть позже даты окончания!");
            }
            return new BookingRequest(this);
        }
    }
}

---

Использование библиотеки Lombok: @Builder и @SuperBuilder

Чтобы избежать написания десятков строк шаблонного кода (boilerplate), в промышленной разработке часто применяется Project Lombok:

import lombok.Builder;
import lombok.Getter;

@Getter
@Builder(toBuilder = true) // toBuilder позволяет создавать измененные копии
public class AccountDto {
    private final String accountId;
    private final String ownerName;
    private final BigDecimal balance;
}

// Изменение одного поля иммутабельного объекта (Wither-семантика):
AccountDto updated = original.toBuilder()
    .balance(new BigDecimal("1500.00"))
    .build();

Наследование с билдером: @SuperBuilder

При наследовании обычный @Builder не видит полей родительского класса. Для решения этой проблемы Lombok предоставляет @SuperBuilder:

import lombok.experimental.SuperBuilder;

@SuperBuilder
public abstract class BaseEntity {
    private final Long id;
    private final Instant createdAt;
}

@SuperBuilder
public class Order extends BaseEntity {
    private final String orderNumber;
}

// Доступны поля обоих классов с сохранением корректного возвращаемого типа Builder:
Order order = Order.builder()
    .id(42L)
    .createdAt(Instant.now())
    .orderNumber("ORD-999")
    .build();

---

🔴 Senior Level

Step Builder (Staged Builder) — типобезопасный компиляторный контроль

Классический Builder не гарантирует на этапе компиляции, что разработчик передал все обязательные поля (ошибка выявляется только в runtime при вызове build()). Паттерн Step Builder заставляет разработчика заполнить обязательные поля строго по цепочке с помощью системы интерфейсов:

public class EmailMessage {
    private final String from;
    private final String to;
    private final String subject;
    private final String body;

    private EmailMessage(String from, String to, String subject, String body) {
        this.from = from;
        this.to = to;
        this.subject = subject;
        this.body = body;
    }

    // Шаги в виде интерфейсов
    public interface FromStep { ToStep from(String from); }
    public interface ToStep { SubjectStep to(String to); }
    public interface SubjectStep { OptionalSteps subject(String subject); }

    public interface OptionalSteps {
        OptionalSteps body(String body);
        EmailMessage build();
    }

    public static FromStep builder() {
        return new StepsExecutor();
    }

    private static class StepsExecutor implements FromStep, ToStep, SubjectStep, OptionalSteps {
        private String from;
        private String to;
        private String subject;
        private String body = "";

        public ToStep from(String from) { this.from = from; return this; }
        public SubjectStep to(String to) { this.to = to; return this; }
        public OptionalSteps subject(String subject) { this.subject = subject; return this; }
        public OptionalSteps body(String body) { this.body = body; return this; }
        public EmailMessage build() { return new EmailMessage(from, to, subject, body); }
    }
}

// Использование: IDE подсказывает только допустимый следующий метод!
EmailMessage msg = EmailMessage.builder()
    .from("support@example.com") // Шаг 1: FromStep
    .to("client@example.com")    // Шаг 2: ToStep
    .subject("Ваш заказ")        // Шаг 3: SubjectStep
    .body("Текст письма")        // Опционально
    .build();

// ❌ Не скомпилируется: попытка вызвать build() без указания обязательного получателя
// EmailMessage.builder().from("a@b.com").build(); 

---

Анализ производительности: Нагрузка на GC и Escape Analysis

Каждый вызов new Builder() аллоцирует промежуточный объект в куче (Young Gen / Eden):

1. Escape Analysis (Анализ побега): JIT-компилятор (HotSpot C2) анализирует область видимости экземпляра Builder. Если ссылка на Builder не «убегает» за пределы метода (не передается в сторонние методы и не сохраняется в поля), компилятор может применить Scalar Replacement (скалярное замещение): поля билдера раскладываются в регистры процессора или стек, и реального выделения памяти в куче не происходит.
2. Ограничения Escape Analysis: Если цепочка вызовов билдера слишком сложна, содержит циклы или вызовы невиртуальных методов, JIT не может доказать отсутствие побега. В приложениях с миллионами запросов в секунду (High-Frequency Trading, обработка телеметрии) аллокация миллионов короткоживущих объектов Builder создает дополнительное давление на сборщик мусора (GC Pressure). В таких hot-path сценариях предпочтительны прямые конструкторы или пулы объектов.

---

Java Records (Java 16+) против Builder

С появлением record многие сценарии DTO упростились:

• record по умолчанию неизменяем, компактен и генерирует канонический конструктор.
• Однако при наличии большого количества компонентов (6+) или необходимости значений по умолчанию record также выигрывает от использования Builder.

public record UserRecord(String id, String username, String email, String role, boolean active) {
    // Компактный конструктор для валидации инвариантов
    public UserRecord {
        if (id == null || username == null) {
            throw new IllegalArgumentException("ID and username are required");
        }
    }

    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private String id;
        private String username;
        private String email;
        private String role = "USER"; // Значение по умолчанию
        private boolean active = true;

        public Builder id(String id) { this.id = id; return this; }
        public Builder username(String u) { this.username = u; return this; }
        public Builder email(String e) { this.email = e; return this; }
        public Builder role(String r) { this.role = r; return this; }
        public Builder active(boolean a) { this.active = a; return this; }

        public UserRecord build() {
            return new UserRecord(id, username, email, role, active);
        }
    }
}

---

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«Паттерн Builder используется для пошагового конструирования сложных объектов, когда класс содержит большое количество параметров (от 4 и более), среди которых много опциональных. Builder решает две ключевые проблемы: устраняет антипаттерн телескопического конструктора (нечитаемые цепочки перегрузок) и предотвращает создание объектов в невалидном промежуточном состоянии, свойственном сеттерам (JavaBeans). Он гарантирует создание полностью валидного, иммутабельного объекта с потокобезопасной публикацией полей (final). В качестве продвинутого варианта применяется Step Builder, обеспечивающий контроль передачи обязательных полей на этапе компиляции».

---

3–4 каверзных вопроса с ответами

1. Почему Builder безопаснее сеттеров с точки зрения многопоточности?
   • Ответ: При использовании сеттеров объект публикуется в память незаполненным, и параллельный поток может прочитать ссылку до того, как будут вызваны все сеттеры, получив поврежденное состояние (Data Race). Builder инкапсулирует сборку внутри вспомогательного класса и отдает целевой объект только в методе build(), где все целевые поля объявлены final, что гарантирует безопасную публикацию по JMM (JSR-133).
2. Как работает Step Builder (Staged Builder) и зачем он нужен?
   • Ответ: Step Builder разделяет создание объекта на последовательность вызовов строго определенных интерфейсов (Step1 -> Step2 -> ... -> OptionalSteps -> build()). Это превращает валидацию обязательных полей из runtime-ошибки в гарантию времени компиляции: вызвать build() невозможно, пока не будут переданы все обязательные параметры.
3. В каких ситуациях использование Builder является антипаттерном?
   • Ответ: Во-первых, для классов с 1–3 параметрами (overengineering, лишний код). Во-вторых, в экстремальных hot-path участках с миллионным RPS, где создание промежуточных объектов-строителей перегружает Eden/GC, если JIT не справился со скалярным замещением (Escape Analysis). В-третьих, если поля созданного класса мутабельны (отсутствует final), что сводит на нет гарантию целостности.
4. Как решить проблему наследования классов при использовании Lombok @Builder?
   • Ответ: Обычный @Builder не работает с иерархиями наследования, так как возвращает билдер текущего класса и не видит родительские поля. Для этого используется аннотация @SuperBuilder над базовым и дочерними классами, которая генерирует обобщенные (generic) билдеры с корректной ковариантностью возвращаемых типов.

---

Типичные ошибки и Red Flags

• 🚩 Использование Builder для классов с 1–2 параметрами — неоправданное усложнение кода (достаточно обычного конструктора).
• 🚩 Отказ от модификатора final для полей целевого класса — созданный билдером объект остается мутабельным и уязвимым к состояниям гонки.
• 🚩 Отсутствие валидации в методе build() — превращение Builder в обычный аналог сеттеров без контроля бизнес-правил.
• 🚩 Игнорирование нагрузки на GC в микросервисах с высоким RPS без профилирования аллокаций.

---

Связанные темы

• В чём разница между Factory Method и Abstract Factory — сравнение порождающих паттернов
• Что такое Prototype pattern — создание объектов клонированием
• Что такое Singleton — обеспечение единственного экземпляра
• Что такое иммутабельность — концепция неизменяемых объектов в Java
• Records и Дженерики — синтаксис современных неизменяемых структур данных