Java 디자인 패턴, 팩토리 패턴 장단점 완벽 정리

🔗 팩토리 패턴이란?

팩토리 패턴(Factory Pattern)은 객체 생성 로직을 별도의 팩토리 클래스나 메서드로 분리하여, 클라이언트 코드가 생성 과정의 세부사항을 몰라도 객체를 생성할 수 있도록 돕는 생성 디자인 패턴입니다.
즉, 어떤 구체적인 클래스의 인스턴스를 생성할지에 대한 결정을 팩토리에 맡김으로써, 객체 생성과 사용을 분리하는 것이 핵심입니다.

이 패턴의 가장 큰 목적은 코드의 유연성과 재사용성을 높이는 것입니다.
팩토리를 활용하면 클라이언트 코드에서는 단일 인터페이스나 추상 클래스를 통해 객체를 생성할 수 있고, 생성 방식이 바뀌더라도 코드 수정 범위를 최소화할 수 있습니다.
예를 들어, 데이터베이스 연결 객체를 생성하는 코드를 생각해봅시다.
MySQL에서 PostgreSQL로 변경할 경우에도 클라이언트 코드는 팩토리를 통해 동일한 메서드 호출만 하면 되므로, 코드 수정이 최소화됩니다.

📌 팩토리 패턴의 기본 구조

팩토리 패턴의 구조는 크게 Product (생성될 객체의 인터페이스나 추상 클래스), Concrete Product (실제 구현 클래스), 그리고 Factory (객체 생성을 담당하는 클래스)로 나눌 수 있습니다.
팩토리는 매개변수나 조건에 따라 적절한 Concrete Product를 반환합니다.

// Product
public interface Shape {
    void draw();
}

// Concrete Product
public class Circle implements Shape {
    public void draw() {
        System.out.println("Draw Circle");
    }
}

// Factory
public class ShapeFactory {
    public Shape getShape(String type) {
        if (type.equals("circle")) {
            return new Circle();
        }
        return null;
    }
}

위 예제에서 클라이언트는 ShapeFactory의 getShape() 메서드만 호출하면, 내부 로직에 따라 Circle 객체가 생성됩니다.
이렇게 하면 객체 생성에 관한 로직이 한 곳에 집중되므로, 관리와 유지보수가 훨씬 용이해집니다.

🛠️ 팩토리 패턴의 주요 특징

팩토리 패턴은 객체 생성 방식을 캡슐화하여, 클라이언트가 생성 과정을 직접 다루지 않고도 필요한 객체를 받을 수 있도록 설계됩니다.
이로 인해 코드의 결합도(coupling)를 낮추고, 향후 유지보수 및 확장성을 높이는 효과가 있습니다.

📌 느슨한 결합(Loose Coupling)

팩토리 패턴을 사용하면 클라이언트가 구체적인 클래스 이름에 의존하지 않고, 인터페이스나 추상 클래스에 의존하게 됩니다.
이는 코드 변경에 대한 영향을 최소화하고, 새로운 타입을 추가할 때 기존 코드를 수정하지 않아도 되는 장점을 제공합니다.

📌 객체 생성 로직의 단일화

객체 생성에 관한 로직이 한 곳(팩토리 클래스)에 모여 있기 때문에, 생성 과정의 변경이 필요할 경우 해당 팩토리만 수정하면 됩니다.
이로 인해 유지보수가 훨씬 쉬워지고, 오류 발생 가능성도 줄어듭니다.

📌 확장 용이성

새로운 제품 클래스가 추가되어도 기존 클라이언트 코드에는 영향을 주지 않고, 팩토리에 새로운 분기나 조건을 추가하는 것만으로 기능을 확장할 수 있습니다.
이는 특히 프로젝트 규모가 커질수록 유용하게 작용합니다.

⚙️ 팩토리 패턴의 장점

팩토리 패턴은 객체 생성의 복잡성을 숨기고, 클라이언트 코드와 생성 로직을 분리하여 유지보수성과 확장성을 크게 향상시킵니다.
실무 환경에서 이 패턴이 널리 사용되는 이유도 바로 이러한 장점 때문입니다.

📌 코드 재사용성 향상

팩토리 메서드를 통해 객체 생성 로직을 중앙에서 관리하면, 동일한 객체 생성 코드를 여러 곳에서 반복 작성할 필요가 없습니다.
이로써 코드 중복이 줄고, 변경이 필요한 경우 한 곳만 수정하면 전체에 반영됩니다.

📌 유지보수 비용 절감

객체 생성 방식이 변경되더라도 팩토리 클래스만 수정하면 되므로, 기존에 해당 객체를 사용하는 모든 코드에는 영향을 주지 않습니다.
이는 대규모 프로젝트에서 변경 사항을 최소화하는 데 매우 유리합니다.

📌 다양한 객체 생성 가능

팩토리 메서드에 매개변수를 전달함으로써, 조건에 따라 서로 다른 객체를 반환할 수 있습니다.
이를 통해 유연한 객체 생성 로직을 구현할 수 있으며, 새로운 객체 타입이 추가되더라도 기존 구조에 쉽게 통합할 수 있습니다.

• 🛠️객체 생성 코드의 중앙 집중화
• ⚙️코드 중복 최소화로 유지보수 용이
• 🔌확장성 높은 구조 설계 가능

🔌 팩토리 패턴의 단점

팩토리 패턴은 많은 장점을 제공하지만, 모든 상황에서 무조건 유리한 것은 아닙니다.
특히 초기 설계나 코드 복잡성 측면에서 몇 가지 단점이 존재합니다.
이 부분을 이해하고 나서 적용 여부를 판단하는 것이 좋습니다.

📌 클래스 수 증가

팩토리 패턴은 객체 생성을 별도의 클래스(팩토리)에서 담당하기 때문에, 프로젝트 내 클래스 수가 증가하는 경향이 있습니다.
특히 다양한 제품군을 다루는 경우, 각 제품군별로 팩토리 클래스를 따로 만들어야 하는 상황이 발생할 수 있습니다.

📌 초기 설계 복잡성

간단한 객체 생성에는 굳이 팩토리 패턴을 적용할 필요가 없는데도, 무리하게 사용하면 설계가 불필요하게 복잡해질 수 있습니다.
또한 팩토리 메서드나 추상 팩토리를 잘못 설계하면, 오히려 유지보수 비용이 증가할 수 있습니다.

📌 디버깅 난이도 상승

팩토리 패턴은 객체 생성 과정이 한 단계 더 추상화되므로, 디버깅 시 생성 로직을 추적하는 데 시간이 더 걸릴 수 있습니다.
특히 대규모 프로젝트에서는 팩토리 메서드가 복잡해질수록 문제 원인을 찾기 어려워질 수 있습니다.

💡 팩토리 패턴 적용 시 주의사항

팩토리 패턴은 잘만 활용하면 객체 생성의 유연성을 극대화할 수 있지만, 남용하면 불필요한 복잡성을 초래할 수 있습니다.
따라서 적용 전에 상황과 요구사항을 꼼꼼히 검토해야 합니다.

📌 적용이 적합한 경우

팩토리 패턴은 객체 생성 과정이 자주 변경되거나, 여러 타입의 객체를 생성해야 하는 경우 특히 효과적입니다.
예를 들어, 결제 시스템에서 카드 결제, 계좌이체, 간편 결제 등 다양한 결제 방식 객체를 생성하는 경우 팩토리 패턴을 적용하면 유지보수가 훨씬 쉬워집니다.

📌 남용을 피해야 하는 경우

단일 객체만 생성하거나 생성 로직이 단순한 경우에는 팩토리 패턴보다 직접 객체를 생성하는 것이 더 효율적일 수 있습니다.
불필요한 추상화는 오히려 코드 가독성과 유지보수를 해칠 수 있습니다.

❓ 자주 묻는 질문 (FAQ)