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

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

Различаете ли вы, какую проблему решает каждый паттерн: фабрика отвечает на вопрос «какой объект создать», строитель на вопрос «как собрать сложный объект по шагам». Следом часто просят найти оба в самом .NET и спрашивают, нужен ли Builder в современном C#.

Как отвечать

Сформулируйте разницу через назначение, потом дайте примеры из платформы:

• Factory: один вызов, на выходе готовый объект, а конкретный тип скрыт за абстракцией. Бывает простая фабрика (метод со switch по параметру), Factory Method из GoF (подкласс переопределяет метод создания) и Abstract Factory (семейство согласованных объектов). В .NET это IHttpClientFactory, ILoggerFactory, фабричные делегаты в DI вроде services.AddScoped<IRepo>(sp => ...);
• Builder: много вызовов с настройкой, в конце Build(), который проверяет согласованность и выдаёт результат. Тип обычно один, сложны порядок и набор параметров. В .NET это StringBuilder, UriBuilder, WebApplication.CreateBuilder(args) с последующим builder.Build(), DbContextOptionsBuilder;
• как совмещаются: фабрика может внутри пользоваться строителем, а строитель может отдавать разные реализации в зависимости от настроек.

Отдельно скажите, что для простых DTO Builder в C# часто лишний: объектные инициализаторы, свойства с init, модификатор required и record с выражением with закрывают задачу без отдельного класса. Строитель оправдан, когда нужна пошаговая сборка с валидацией, неизменяемый результат или fluent API для библиотеки.

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

Называют любой статический Create() паттерном Factory Method. У GoF он завязан на наследование и полиморфный метод создания, простая фабрика это другое, хоть и полезное.

Пишут Builder для класса с тремя полями. Интервьюер спросит, чем это лучше инициализатора с required, и ответа не будет.

Делают Build() без проверок, и строитель выдаёт наполовину заполненный объект. Смысл метода как раз в том, чтобы отказаться собирать некорректное состояние и бросить исключение.