본문 바로가기
LV3_Advanced/GOF 패턴

Factory Method (팩토리 메서드)

by 하타라시 2026. 2. 28.

목차

💡
  • 왜 팩토리 메서드 패턴을 사용해야 하는가?
  • 설계도는 어떻게 생겼나?
  • 실제로 어떻게 구현하나?
  • 장점과 단점은 무엇인가?

왜 팩토리 메서드 패턴을 사용해야 하는가?

객체 생성 로직을 분리하여, 어떤 객체를 생성할지에 대한 결정을 하위 클래스에 위임하기 위해 사용합니다.

즉, 객체를 new 키워드로 생성하는 대신, 생성 책임을 팩토리 메서드에 위임합니다.

이러한 형태는 새로운 종류의 객체가 추가되더라도 팩토리 클래스만 확장하면 되므로, 확장에 매우 유연합니다.

⇒ 생성과 사용의 책임을 분리하므로 결합도까지 낮추는 패턴입니다.

설계도는 어떻게 생겼나?

팩토리 메서드 패턴은 제품 구현 영역과 제품 생성 영역을 구분하는 구조입니다.

제품 구현은 제품 인터페이스와 제품 구현 클래스가 담당하며,

제품 생성은 팩토리 추상 클래스와 팩토리 구현 클래스가 담당합니다.

이처럼 생성 책임을 분리함으로써, 구체 제품에 대한 직접적인 의존이 줄어들고, 구조의 결합도가 낮아지게 됩니다.

즉 팩토리 메서드 패턴은 제품 구현 클래스가 아닌 제품 인터페이스 클래스에 의존합니다.

실패

실제로 어떻게 구현하나?

제품 규격 인터페이스

public interface Notification {
    void send();
}

제품 구현 클래스

public class EmailNotification implements Notification {
    @Override
    public void send() {
        System.out.println("이메일을 전송합니다.");
    }
}

public class SmsNotification implements Notification {
    @Override
    public void send() {
        System.out.println("문자를 전송합니다.");
    }
}

팩토리 추상 클래스

public abstract class NotificationFactory {

    // 🌟 팩토리 메서드
    public abstract Notification createNotification();

    // 생성된 객체를 사용하는 공통 로직
    public void notifyUser() {
        Notification notification = createNotification();
        notification.send();
    }
}

팩토리 구현 클래스

public class EmailFactory extends NotificationFactory {
    @Override
    public Notification createNotification() {
        return new EmailNotification();
    }
}

public class SmsFactory extends NotificationFactory {
    @Override
    public Notification createNotification() {
        return new SmsNotification();
    }
}

실제 사용

public class Main {
    public static void main(String[] args) {

        NotificationFactory factory;

        // 상황에 따라 팩토리 선택
        factory = new EmailFactory();
        factory.notifyUser();

        factory = new SmsFactory();
        factory.notifyUser();
    }
}

장점과 단점은 무엇인가?

장점

  • 개방 폐쇄 원칙 준수
    • 새로운 방식이 추가되어도 기존 로직을 수정하지 않고 새로운 팩토리만 추가하면 됩니다.
  • 결합도 감소
    • 클라이언트는 구체 클래스를 알 필요가 없습니다.
  • 생성과 사용의 분리
    • 객체 생성 로직을 한 곳으로 모아 관리할 수 있습니다.

단점

  • 클래스 수 증가
    • 제품이 추가될 때마다 새로운 팩토리 하위 클래스도 필요합니다.
  • 구조 복잡도 증가 가능성
    • 단순한 객체 생성에 까지 적용하면 오히려 과도한 설계가 될 수 있습니다.