[디자인 패턴] - Factory Method

Factory Method 패턴

객체 생성의 책임을 서브클래스로 위임하여 객체 생성을 캡슐화하는 패턴이다.

⇒ 객체를 직접 생성하는 것이 아니라, 서브클래스에서 생성 방식을 정의하도록 하는 패턴이다.

⇒ 클라이언트는 new 키워드를 직접 사용하지 않으며, 대신 팩토리 메서드를 호출하여 객체를 얻는다.

⇒ 새로운 객체가 추가될 때, 기존 코드를 변경하지 않고 새로운 서브클래스를 추가하는 것만으로 확장 가능하다.(= 유연성과 확장성이 뛰어나다.)

 

예제 코드

// 1. Product (추상 제품)
interface Document {
    void open();
}

// 2. Concrete Product (구체적인 제품)
class WordDocument implements Document {
    public void open() {
        System.out.println("Opening a Word document...");
    }
}

class PDFDocument implements Document {
    public void open() {
        System.out.println("Opening a PDF document...");
    }
}

// 3. Creator (팩토리 메서드를 포함한 추상 클래스)
abstract class DocumentCreator {
    // 팩토리 메서드 (서브클래스에서 구현할 메서드)
    public abstract Document createDocument();

    // 공통 동작을 정의할 수 있음
    public void openDocument() {
        Document doc = createDocument();
        doc.open();
    }
}

// 4. Concrete Creator (구체적인 팩토리 클래스)
class WordDocumentCreator extends DocumentCreator {
    public Document createDocument() {
        return new WordDocument();
    }
}

class PDFDocumentCreator extends DocumentCreator {
    public Document createDocument() {
        return new PDFDocument();
    }
}

// 5. Client (사용 예제)
public class FactoryMethodExample {
    public static void main(String[] args) {
        // 팩토리 객체 생성
        DocumentCreator creator;

        // Word 문서 생성
        creator = new WordDocumentCreator();
        creator.openDocument();

        // PDF 문서 생성
        creator = new PDFDocumentCreator();
        creator.openDocument();
    }
}

 

실행결과

Opening a Word document...
Opening a PDF document...

 

Factory Method 패턴의 장점

객체 생성 코드의 변경 없이 새로운 객체를 추가할 수 있다.

• 새로운 Document 타입을 추가하려면 ConcreteProduct와 ConcreteCreator만 추가하면 된다.
• 기존 DocumentCreator나 Client 코드는 수정할 필요가 없다.

 

OCP(Open-Closed Principle, 개방-폐쇄 원칙) 준수

기존 코드를 수정하지 않고도 기능을 확장할 수 있어 유지보수가 용이하다.

 

객체 생성 로직을 한 곳에서 관리

new 키워드를 직접 사용하지 않고 팩토리 메서드에서 관리하므로, 코드의 중복이 줄어든다.

 

 

 

코드의 일관성 유지

객체를 생성하는 방식이 통일되어 있어, 객체 생성 과정에서의 실수를 줄일 수 있다.

 

의존성 감소 (느슨한 결합, Loose Coupling)

클라이언트는 구체적인 클래스가 아닌 인터페이스 또는 추상 클래스에 의존하므로 코드 변경 시 영향을 덜 받는다.

 

Factory Method 패턴의 단점

구현할 클래스가 많아진다.(클래스 증가)

• 팩토리 클래스가 하나 추가될 때마다 새로운 ConcreteProduct와 ConcreteCreator를 만들어야 한다.
• 작은 프로젝트에서는 오히려 코드가 복잡해질 수 있다.

 

코드의 복잡성이 증가할 수 있다.

단순한 객체 생성에 Factory Method 패턴을 사용하면 오버헤드가 발생할 수 있다.

ex) 단순한 User 객체를 생성할 때 Factory Method를 사용하면 불필요한 코드가 많아질 수 있다.

 

객체 생성 방식이 명확하지 않을 수 있다.

직접 new를 사용하는 것보다 코드가 직관적이지 않을 수 있다.

 

Factory Method 패턴을 언제 사용할까?

객체 생성이 자주 변경될 가능성이 있을 때

 

다양한 타입의 객체를 생성해야 하거나, 새로운 객체가 추가될 가능성이 많을 때 사용한다.

 

객체 생성을 서브클래스에서 결정해야 할 때

부모 클래스에서 객체를 생성하는 메서드를 정의하고, 실제 어떤 객체를 반환할지는 하위 클래스에서 결정하는 경우 사용한다 .

 

클라이언트 코드가 구체적인 클래스에 의존하지 않도록 만들고 싶을 때

클라이언트가 new 키워드를 사용하지 않고, 팩토리 메서드를 호출하여 유연한 객체 생성 가능하다.

 

Factory Method 패턴을 사용하지 않아도 되는 경우

객체 생성이 단순한 경우

생성자가 하나뿐인 단순한 객체라면 굳이 팩토리 패턴을 사용할 필요가 없다.

ex) new User("Alice", 20)와 같이 간단한 생성 로직

 

객체 생성 방식이 변경될 가능성이 없는 경우

객체의 종류가 고정되어 있고, 추가될 가능성이 없다면 팩토리 패턴을 사용하는 것이 불필요한 오버헤드가 될 수 있다.

 

정리하자면

• Factory Method 패턴은 객체 생성의 책임을 하위 클래스로 위임하여, 유연하고 확장 가능한 구조를 만들 수 있는 강력한 디자인 패턴이다.
• 객체 생성이 자주 변경되거나, 다양한 타입의 객체를 생성해야 할 때 유용하다.
• 불필요하게 사용하면 코드가 복잡해지고 유지보수가 어려워질 수 있으므로, 상황에 맞게 적절히 활용하는 것이 중요하다.