JAVA 팩토리 디자인 패턴으로 객체 생성 로직을 유연하게 관리하는 방법

🔗 팩토리 패턴이란?

팩토리 패턴(Factory Pattern)은 객체 생성의 책임을 하나의 클래스 또는 메서드로 분리하여
객체를 생성하는 방식을 캡슐화하는 디자인 패턴입니다.
일반적으로 객체를 직접 new 키워드로 생성하는 대신,
팩토리 클래스나 메서드를 통해 생성하도록 구성합니다.

이렇게 하면 객체 생성 로직을 코드 전체에서 통합적으로 관리할 수 있어
유지보수가 편리하고, 새로운 객체 유형이 추가될 경우에도 기존 코드를 수정하지 않고 확장할 수 있는
OCP(개방-폐쇄 원칙)을 지킬 수 있게 됩니다.

💬 팩토리 패턴은 객체 생성이라는 핵심 로직을 캡슐화함으로써,
코드의 유연성과 확장성을 동시에 확보할 수 있도록 도와줍니다.

📌 왜 팩토리 패턴이 필요한가요?

예를 들어 여러 종류의 결제 방식(신용카드, 페이팔, 계좌이체 등)을 사용하는 앱을 만든다고 해볼게요.
사용자 선택에 따라 서로 다른 객체를 생성해야 할 경우,
코드 곳곳에서 if-else 문으로 직접 객체를 생성하면 유지보수가 어려워지죠.
이럴 때 팩토리 패턴을 활용하면 객체 생성 로직을 한 곳으로 모아
유형이 늘어나도 기존 코드를 손대지 않고도 대응할 수 있습니다.

🛠️ 팩토리 패턴의 구조와 동작 방식

팩토리 패턴은 크게 세 가지 구성 요소로 이뤄집니다.
제품(Product), 팩토리(Factory), 클라이언트(Client)가 그 주인공이죠.
클라이언트는 직접 객체를 생성하지 않고 팩토리를 통해 제품 객체를 요청하게 됩니다.
이 구조는 추상화를 통해 객체 생성의 세부 사항을 감추고,
새로운 클래스가 추가되어도 클라이언트 코드는 변경 없이 유지됩니다.

• 🏭Product: 공통 인터페이스 또는 추상 클래스
• 🏗️ConcreteProduct: 실제 구현 클래스
• ⚙️Factory: 객체 생성 책임을 담당하는 클래스
• 🧑‍💻Client: 팩토리에게 객체 생성을 요청하는 사용자

📌 클래스 간의 관계 이해하기

팩토리 패턴에서는 객체 생성의 흐름을 계층적으로 정리합니다.
클라이언트는 팩토리에게 특정 조건을 넘기고, 팩토리는 그 조건에 맞는 제품 객체를 반환합니다.
덕분에 클라이언트는 객체가 어떤 방식으로 생성되었는지 신경 쓰지 않아도 되죠.
즉, 객체 생성의 책임과 사용의 책임이 분리되며, 이로 인해 코드의 결합도가 낮아지고 테스트가 쉬워집니다.

// 간단한 예시 흐름
interface Product {
    void use();
}

class ConcreteProductA implements Product {
    public void use() {
        System.out.println("A 제품 사용");
    }
}

class ProductFactory {
    public Product create(String type) {
        if ("A".equals(type)) return new ConcreteProductA();
        // 다른 제품은 생략
        return null;
    }
}

이처럼 팩토리 패턴은 객체 생성에 대한 고민을 분산시키고,
변화에 유연하게 대처할 수 있도록 도와주는 구조적인 해결책이 됩니다.

⚙️ JAVA로 구현하는 팩토리 패턴 예제

팩토리 패턴의 개념을 이해했다면, 이제 실제 JAVA 코드로 구현해볼 차례입니다.
이번 예제는 다양한 형태의 버튼(Button)을 생성하는 시나리오를 가정해 보겠습니다.
버튼의 종류는 ‘윈도우 버튼’, ‘맥 버튼’으로 나뉘며,
클라이언트는 어떤 버튼이 생성되는지 몰라도 그 기능을 사용할 수 있습니다.

📌 JAVA 코드 예시

// 1. Product 인터페이스
interface Button {
    void render();
}

// 2. Concrete Products
class WindowsButton implements Button {
    public void render() {
        System.out.println("Rendering Windows Button");
    }
}

class MacButton implements Button {
    public void render() {
        System.out.println("Rendering Mac Button");
    }
}

// 3. Factory
class ButtonFactory {
    public static Button createButton(String osType) {
        if (osType.equalsIgnoreCase("Windows")) {
            return new WindowsButton();
        } else if (osType.equalsIgnoreCase("Mac")) {
            return new MacButton();
        }
        throw new IllegalArgumentException("Unknown OS type");
    }
}

// 4. Client
public class App {
    public static void main(String[] args) {
        Button button = ButtonFactory.createButton("Mac");
        button.render();  // Output: Rendering Mac Button
    }
}

위 코드에서 ButtonFactory는 클라이언트로부터 OS 종류를 전달받아
적절한 버튼 객체를 생성합니다.
클라이언트는 내부 구현에 대한 정보 없이도 버튼을 생성하고 사용할 수 있어
높은 수준의 추상화와 유연성을 확보할 수 있습니다.

🔌 팩토리 패턴이 유용한 상황

팩토리 패턴은 단순히 객체 생성을 분리하는 것에 그치지 않습니다.
복잡하고 다양한 객체가 존재하거나, 객체 생성 로직이 조건에 따라 바뀌는 환경에서는
팩토리 패턴이 필수에 가깝다고 볼 수 있어요.
그럼 어떤 상황에서 이 패턴을 사용하면 좋은지 살펴볼까요?

📌 조건에 따라 객체가 달라져야 할 때

예를 들어 주문 처리 시스템에서 결제 방식이 ‘카드’, ‘계좌이체’, ‘휴대폰 결제’처럼 다양할 경우,
사용자의 선택에 따라 적절한 결제 클래스가 생성되어야 합니다.
팩토리 패턴을 사용하면 조건 분기 없이 객체 생성을 분리할 수 있어
코드가 훨씬 깔끔해지고 테스트도 수월해집니다.

📌 인터페이스 기반 설계가 필요할 때

여러 객체가 동일한 인터페이스를 구현하고 있고,
이 중 어떤 객체를 사용할지 동적으로 결정해야 한다면
팩토리 패턴을 통해 인터페이스와 구현체 사이의 결합도를 낮출 수 있습니다.
이 방식은 SOLID 원칙 중 DIP(의존 역전 원칙)을 따르기에 특히 유리합니다.

📌 유지보수가 자주 필요한 프로젝트

제품 종류가 자주 추가되거나, 객체 생성 방식이 자주 변경되는 프로젝트의 경우
팩토리 클래스를 통해 생성 로직을 한 곳에서 관리할 수 있으므로
코드 전체의 변경 범위를 최소화할 수 있습니다.
결국 더 적은 리스크로 새로운 기능을 추가할 수 있게 됩니다.

💡 팩토리 패턴과 다른 생성 패턴 비교

팩토리 패턴 외에도 객체 생성을 다루는 다양한 디자인 패턴들이 존재합니다.
이 중에서도 자주 비교되는 패턴으로는 추상 팩토리(Abstract Factory),
빌더(Builder), 프로토타입(Prototype) 패턴이 있습니다.
각 패턴은 생성 목적과 구조에서 차이를 가지며,
적용해야 할 상황이 다르기 때문에 차이를 명확히 이해하는 것이 중요합니다.

📌 주요 생성 패턴 비교 표

📌 팩토리 vs 추상 팩토리

팩토리 패턴은 단일 제품을 생성하는 데에 초점이 맞춰져 있지만,
추상 팩토리 패턴은 제품군 전체를 생성할 수 있는 구조를 제공합니다.
UI 컴포넌트를 예로 들면, 윈도우 UI 버튼, 체크박스, 슬라이더를 모두 하나의 팩토리에서 제공할 수 있는 것이죠.

📌 팩토리 vs 빌더

빌더 패턴은 객체 구성 과정이 복잡할 때 유용합니다.
각 단계별로 객체를 설정한 뒤 마지막에 빌드하는 방식으로
팩토리 패턴보다 더 세밀한 제어가 가능합니다.
대표적으로 HTML 생성기, SQL 쿼리 생성기 등이 이에 해당하죠.

❓ 자주 묻는 질문 (FAQ)