В чем разница между паттернами Builder и Factory и для чего они нужны

Что проверяют

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

Как отвечать

Оба про создание объектов, но отвечают на разные вопросы.

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

Строитель отвечает на вопрос «как собрать объект с множеством параметров». Он нужен, когда у конструктора десяток аргументов, часть необязательна, и порядок легко перепутать. Собирает пошагово, проверяет условия в конце и отдаёт готовый, обычно неизменяемый объект.

Job job = Job.builder()
    .title("Backend Developer")
    .remote(true)
    .salaryFrom(250_000)
    .build();

Что добавить, чтобы ответ звучал практично: в Java строитель почти вытеснен там, где хватает record и именованных фабричных методов (Job.remote(...)), а в Kotlin он вообще не нужен благодаря именованным аргументам и значениям по умолчанию. Фабрика же продолжает жить в виде статических фабричных методов (List.of, Optional.of, Integer.valueOf), и это самая частая её форма.

Ловушка, которую стоит упомянуть: строитель без обязательных проверок в build() позволяет собрать объект в недопустимом состоянии, и тогда он вреднее конструктора.

Где спотыкаются

Называют строителем любой класс с цепочкой методов, даже если он ничего не собирает.

Пишут строитель для трёх полей, где хватило бы конструктора.

Путают статический фабричный метод с паттерном «фабричный метод»: первый это приём, второй это делегирование решения подклассу.