Builder vs Factory 핵심 비교표

항목	Builder 패턴	Factory 패턴
목적	복잡한 객체를 단계적으로 생성	객체 생성 캡슐화 및 다형성 처리
주요 특징	필드별로 유연하게 설정 가능	서브 클래스 결정, 생성 로직 감춤
사용 예	DTO, Entity, 복잡한 설정 객체	전략 패턴, DB 커넥션, 전략별 서비스
Spring에서	@Builder, Lombok	@Bean, Factory 클래스, ApplicationContext.getBean() 등

Builder 패턴 예제 (Lombok 기반)

@Builder
public class User {
    private String name;
    private int age;
    private String email;
}

User user = User.builder()
                .name("kim")
                .email("kim@example.com")
                .age(25)
                .build();

장점:

• 가독성 좋고, 필드 순서 상관없이 선택적으로 설정 가능
• 생성자가 너무 많을 때 구조가 깔끔해짐
• 불변 객체 생성에 적합 (final과 조합)

단점:

• 클래스 수 증가 가능 (빌더 클래스 내부 생성됨)
• @Builder.Default 같은 설정 안 하면 초기화 누락될 수도 있음

Factory 패턴 예제

인터페이스 + 구현체 + 팩토리

public interface PaymentService {
    void pay(int amount);
}

public class KakaoPayService implements PaymentService {
    public void pay(int amount) {
        System.out.println("KakaoPay로 결제: " + amount);
    }
}

public class PaycoService implements PaymentService {
    public void pay(int amount) {
        System.out.println("Payco로 결제: " + amount);
    }
}

public class PaymentFactory {

    public static PaymentService getService(String type) {
        switch (type) {
            case "kakao": return new KakaoPayService();
            case "payco": return new PaycoService();
            default: throw new IllegalArgumentException("지원 안 함");
        }
    }
}

PaymentService service = PaymentFactory.getService("kakao");
service.pay(5000);

장점:

• 객체 생성 로직 감춤 (캡슐화)
• 조건/환경에 따라 객체 다르게 반환 가능
• 인터페이스 기반으로 다형성 구현하기 좋음

단점:

• 조건문이 많아지면 OCP(Open-Closed Principle) 위반 가능
• DI와 함께 쓰지 않으면 테스트 어려워짐

사용 시점 요약

상황	추천 패턴
필드가 많고 생성자 인자가 복잡한 경우	✅ Builder
구현체가 여러 개 있고 런타임에 결정되는 경우	✅ Factory
외부 라이브러리 객체 설정이 복잡할 때	Builder or Factory 모두 가능
Spring에서 Bean 생성 조건 다를 때	Factory + DI 조합 (@Bean, @Conditional)