[디자인 패턴] 생성패턴 - Factory Method Pattern (팩토리 메서드 패턴)

목차

 

📇 개요

Factory 패턴은 객체 생성과 관련된 디자인 패턴이다.

Simple Factory 패턴은 객체 생성 역할을 담당하면서 각 클라이언트에서 구현 클래스에 직접 의존하지 않도록 분리한다.

하지만 "새로운 클래스가 추가되었을 때 Factory 클래스를 수정해야 한다"는 한계가 있다.

기존 코드의 변경 없이 확장하기 위한 디자인 패턴이 바로 Factory Method 패턴이다.

 

• 생성 패턴 중 하나로 객체를 생성할 때 어떤 클래스의 인스턴스를 만들 지 서브 클래스에서 결정한다.
• 즉, 인스턴스 생성을 서브 클래스에게 위임한다.
• 부모 추상 클래스는 인터페이스에만 의존하고 실제로 어떤 구현 클래스를 호출할 지는 서브 클래스에서 구현한다.
• 새로운 구현 클래스가 추가되어도 기존 Factory 코드의 수정 없이 새로운 Factory 를 추가하면 된다는 장점이 있다.

 

 

👩🏻‍💻 코드로 알아보자

// 크리에이터 클래스는 제품 클래스의 객체를 반환해야 하는 팩토리 메서드를 선언합니다.
abstract class Dialog {

    // 팩토리 메서드 (자식 클래스가 오버라이드 해야 함)
    abstract Button createButton();

    // 팩토리 메서드에서 반환된 제품 객체에 의존하는 비즈니스 로직
    public void render() {
        // 팩토리 메서드를 호출하여 제품 객체를 생성
        Button okButton = createButton();
        // 생성된 제품을 사용
        okButton.onClick(() -> System.out.println("Dialog closed"));
        okButton.render();
    }
}

// 구상 크리에이터: WindowsDialog
class WindowsDialog extends Dialog {
    @Override
    Button createButton() {
        return new WindowsButton();
    }
}

// 구상 크리에이터: WebDialog
class WebDialog extends Dialog {
    @Override
    Button createButton() {
        return new HTMLButton();
    }
}

// 제품 인터페이스: Button
interface Button {
    void render();        // 버튼을 렌더링
    void onClick(Runnable action); // 클릭 이벤트 핸들러 설정
}

// 구상 제품: WindowsButton
class WindowsButton implements Button {
    @Override
    public void render() {
        System.out.println("Rendering a Windows-style button.");
    }

    @Override
    public void onClick(Runnable action) {
        System.out.println("Binding a native OS click event.");
        action.run();
    }
}

// 구상 제품: HTMLButton
class HTMLButton implements Button {
    @Override
    public void render() {
        System.out.println("Rendering an HTML button.");
    }

    @Override
    public void onClick(Runnable action) {
        System.out.println("Binding a web browser click event.");
        action.run();
    }
}

// 애플리케이션 클래스
class Application {
    private Dialog dialog;

    // 현재 설정 또는 환경 설정에 따라 크리에이터의 유형을 선택
    public void initialize() {
        String configOS = readApplicationConfigFile();

        if ("Windows".equalsIgnoreCase(configOS)) {
            dialog = new WindowsDialog();
        } else if ("Web".equalsIgnoreCase(configOS)) {
            dialog = new WebDialog();
        } else {
            throw new RuntimeException("Error! Unknown operating system.");
        }
    }

    // 애플리케이션의 진입점
    public void main() {
        initialize();
        dialog.render();
    }

    // 애플리케이션 환경설정을 읽어오는 메서드 (예시용)
    private String readApplicationConfigFile() {
        // 실제 환경설정을 읽는 로직이 들어가야 함
        // 여기서는 예시로 Windows 반환
        return "Windows";
    }

    public static void main(String[] args) {
        Application app = new Application();
        app.main();
    }
}

 

 

 

☘️ 장/단점

장점

• 크리에이터와 구상 제품들이 단단하게 결합되지 않도록 할 수 있다. (제품 인터페이스에 의존하기 때문)
• 단일 책임 원칙(SRP) : 제품 생성 코드를 프로그램의 한 위치로 이동하여 코드를 더 쉽게 유지관리할 수 있다.
• 개방/폐쇄 원칙(OCP) : 기존 클라이언트 코드를 훼손하지 않고 새로운 유형의 제품들을 프로그램에 도입할 수 있다.

단점

• 패턴을 구현하기 위해 많은 새로운 자식 클래스들을 도입해야 하므로 코드가 더 복잡해질 수 있다.

 

🔄 다른 패턴과의 관계

• 많은 디자인은 복잡성이 낮고 자식 클래스들을 통해 더 많은 커스터마이징이 가능한 팩토리 메서드로 시작해 더 유연하면서도 더 복잡한 추상 팩토리, 프로토타입 또는 빌더 패턴으로 발전된다.
• 추상 팩토리 클래스들은 팩토리 메서드들의 집합을 기반으로 하는 경우가 많다. 또한, 프로토타입을 사용하여 추상 팩토리의 구상 클래스들의 생성 메서드들을 구현할 수 있다.
• 팩토리 메서드를 반복자와 함께 사용하여 컬렉션 자식 클래스들이 해당 컬렉션들과 호환되는 다양한 유형의 반복자들을 반환하도록 할 수 있다.
• 팩토리 메서드는 템플릿 메서드의 특수화라고 생각할 수 있다. 동시에 대규모 템플릿 메서드의 한 단계의 역할을 팩토리 메서드가 할 수 있다.

 

 

 

 

 

📋 참고

• https://bcp0109.tistory.com/367
• https://refactoring.guru/ko/design-patterns/factory-method