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

 

팩토리 메서드 패턴은 생성 패턴 중 하나로 객체 생성을 공장 클래스에게 위임하는 패턴을 말한다. 클라이언트가 구체 클래스를  직접 언급하여 `new` 연산자를 호출하는 대신, 만들고자 하는 객체의 생성 책임을 맡은 공장 클래스에게 객체 생성을 맡긴다.

이름 그대로 객체를 만들어내는 공장(Factory)를 만드는 패턴이라고 할 수 있다. 공장 클래스에서 객체를 만드는 인터페이스를 제공하며, (여기서 인터페이스란 객체 생성을 하는 메서드를 뜻한다. `ShapeFactory`에서는 `createShape()` 메서드가 인터페이스라고 할 수 있다.) 해당 메서드를 포함하는 인터페이스, 즉 공장 클래스를 상속 받는 공장 서브 클래스가 만들 객체의 유형을 결정한다.

 

공장 인터페이스: 객체 생성 메서드를 정의하는 인터페이스.

서브 공장 클래스: 어떤 구체 클래스를 생성할지 결정함.

 

예를 들어서, `Shape` 인터페이스가 존재하고 그를 상속받는 `Circle`과 `Rectangle` 클래스가 존재할 경우 이 `shape` 객체를 생성하기 위해 팩토리 메서드 패턴을 사용한다고 했을 때, `ShapeFactory`라는 공장 인터페이스가 있고 그를 상속받는 `CircleFactory` 클래스와 `RectangleFactory` 클래스를 생성한다.

이렇게 객체 생성 공장이 따로 존재한다면 `Circle` 객체를 생성하고자 하는 클라이언트 `Main`은 `Circle` 구체 클래스를 전혀 모르고도 해당 클래스로부터 객체를 생성할 수 있다. 마트에서는 판매를 위해 과자가 필요하지만 과자를 만드는 방법은 모르는 것과 같다. 공장에게 과자를 주문하면 공장에서 과자를 만들어서 마트에 공급하는 것과 유사하다. 여기서 마트는 클라이언트, 공장은 공장 클래스라고 할 수 있다.

 

//	인터페이스
interface Shape {
    void draw();
}

//	구현 클래스
class Circle implements Shape {
    @Override
    public void draw() {
        System.out.println("동그라미를 그립니다.");
    }
}

class Rectagle implements Shape {
    @Override
    public void draw() {
        System.out.println("직사각형을 그립니다.");
    }
}

//	공장 인터페이스
interface ShapeFactory {
    Shape createShape();
}

//	공장 서브 클래스(구현 클래스)
class CircleFactory implements ShapeFactory {
    @Override
    public Shape createShape() {
        return new Circle();
    }
}

//	공장 서브 클래스(구현 클래스)
class RectangleFactory implements ShapeFactory {
    @Override
    public Shape createShape() {
        return new Rectangle();
    }
}

 

//	클라이언트
public class Main {
    public static void main(String[] args) {
        // CircleFactory를 사용하여 Circle을 생성함
        ShapeFactory circleFactory = new CircleFactory();
        Shape circle = circleFactory.createShape();
        
        // 출력: 동그라미를 그립니다.
        circle.draw(); 
        
        // RectangleFactory를 사용하여 Rectangle을 생성함
        ShapeFactory rectangleFactory = new RectangleFactory();
        Shape rectangle = rectangleFactory.createShape();
        
        //  출력 : 직사각형을 그립니다.
        rectangle.draw(); 
    }
}

 

 

 

 

스프링에서 사용되는 `AppConfig` 또한 팩토리 메서드 패턴의 일종이다. 객체 생성을 위한 메서드가 모여있다. 객체 생성의 책임을 갖는 클래스인 것이다.

 

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy(){
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }

}

 

`memberService()`의 구현 객체는 `memberRepository()` 즉 DAO 기능을 하는 객체에 의존하고 있다. 이 `AppConfig` 객체가 객체의 생성을 담당함과 동시에 의존성 주입의 책임도 담당하고 있는 것이다. 

 

 

팩토리 메서드 패턴에서 공장 클래스는 주로 객체 생성의 책임뿐 아니라 더 확장될 수 있다.

1. 기본적인 책임은 객체를 생성하는 것이다.

2. 해당 객체의 초기값을 설정하거나 의존성을 주입할 수 있다.

3. 오브젝트 풀을 관리하여 새로운 객체를 생성하는 대신 기존의 객체를 재활용할 수 있다.

 

 

예를 들어, 웹 애플리케이션의 서버와 DB의 연결은 비용이 많이 든다. `Connection`객체를 생성하고, DB에 연결하고, 쿼리를 보내고, 결과값을 받아 처리하는 과정이 계속 반복되기 때문이다. 따라서 요청이 들어올 때마다 객체를 생성한다면 비용이 감당할 수 없이 커지게 된다.  여기서도 가장 큰 비용을 차지하는 것이 바로 DB와 연결하는 과정인데, 이때 미리 `Connection` 객체를 여러 개 만들어 두고 요청이 들어올 때마다 빌려주는 방법을 이용한다면 `Connection` 객체를 여러번 생성하는 비용을 줄일 수 있다. 이렇게 객체의 할당 그러니까 생성과 삭제의 비용이 크거나 자주 일어나는 경우에 이러한 패턴을 사용하면 성능에서 크게 이득을 볼 수 있다. 이렇게 `Connection` 객체를 여러개 생성해두고 요청이 올 때마다 대여해주었다가 다시 반환받는 것을 커넥션 풀이라고 하는데, 동시 접속자가 많을 경우에 요청 시마다 `Connection` 객체를 생성해서 할당해주는 것이 아니라 (요청이 올 때마다 객체를 생성한다면 시간이 더 오래 걸리겠죠?) 이미 만들어둔 `Connection` 객체를 할당해주고 재사용하기를 반복한다. 이때 모든 `Connection` 이 사용되고 있다면 `Connection` 이 반환될 때까지 번호순대로 대기 상태로 기다리게 된다. 

 

우리가 상품 관리 시스템, GOODS 클래스를 만들었을 때 사용되었던 `JDBCTemplate`이 `ConnectionFactory`라고 할 수 있다. 우리가 `Connection` 객체를 생성할 필요 없이 이미 템플릿이 정의되어 있어서 해당 클래스에서 `getConnection()`을 호출하기만 하면 `Connection`을 가져올 수 있었다. `Connection` 객체를 가져오는 클라이언트, 즉 DAO에서는 어떤 DB에 연결되는지 구체적인 코드를 모르고도 `Connection` 객체를 생성할 수 있다.

 

그런데 여기서, 우리는 편의성을 위해 JDBC Template을 static 메서드로 선언하고 사용하였지만 Spring에서 사용되는 JDBC Template은 유사하지만 조금 다르다고 할 수 있다. Spring에서는 DAO가 `JDBCTemplate`을 멤버 필드를 가지고 있다. 이때 DAO는 `JDBCTemplate`에 의존한다고 표현할 수 있다. 그리고 여기서 또 `JDBCTemplate`은 `DataSource`에게 의존하고 있다. 아까 커넥션 풀에 대해서 얘기했는데, 웹에서는 사용자가 한두명이 아니라 많은 수의 유저가 동시에 접근하기 때문에 Spring은 커넥션 풀을 관리한다. 이 커넥션 풀을 관리하는 것이 `DataSource`이다. 이 `DataSource`가 `getConnection()` 메서드를 가지고 있다. Spring의  `DriverManagerDataSource`, `HikariDataSource` 등이 `DataSource`를 구현한 클래스 중 하나다. 어떤 클래스에 `DataSource`를 생성하는 메서드가 있다면, 이 메서드는 팩토리 메서드에 해당한다.

 

 

이처럼 공장 클래스의 책임은 요구 사항에 따라 달라질 수 있다. 

 

공장 클래스가 반드시 인터페이스로 선언되어야 하는 것은 아니지만 일반적으로 객체 생성 메서드의 구현을 강제하기 위해 인터페이스로 설정한다. JDK 1.9부터는 인터페이스에 default 메서드 선언이 허용되므로 공장 클래스를 인터페이스로 선언하는 것이 좋은 선택일 수 있다.

 

 

// 교통 수단 인터페이스
interface Vehicle {
    void startEngine();
}

// 구현 클래스: 차
class Car implements Vehicle {
    @Override
    public void startEngine() {
        System.out.println("자동차가 출발합니다~!");
    }
}

// 구현 클래스: 트럭
class Truck implements Vehicle {
    @Override
    public void startEngine() {
        System.out.println("트럭이 출발합니다~!");
    }
}

// 구현 클래스: 오토바이
class Motorcycle implements Vehicle {
    @Override
    public void startEngine() {
        System.out.println("오토바이 출발~!");
    }
}

 

// 교통 수단 인터페이스
interface VehicleFactory {
    Vehicle createVehicle();
}

// 차 생성 공장
class CarFactory implements VehicleFactory {
    @Override
    public Vehicle createVehicle() {
        return new Car();
    }
}

// 트럭 생성 공장
class TruckFactory implements VehicleFactory {
    @Override
    public Vehicle createVehicle() {
        return new Truck();
    }
}

// 오토바이 생성 공장
class MotorcycleFactory implements VehicleFactory {
    @Override
    public Vehicle createVehicle() {
        return new Motorcycle();
    }
}

 

// 클라이언트

public class Main {
    public static void main(String[] args) {
        // CarFactory로 자동차 생성
        VehicleFactory carFactory = new CarFactory();
        Vehicle car = carFactory.createVehicle();
        // 출력: 자동차가 출발합니다~!
        car.startEngine(); // Output: Car Engine Started
        
        // TruckFactory로 트럭 생성
        VehicleFactory truckFactory = new TruckFactory();
        Vehicle truck = truckFactory.createVehicle();        
        // 출력: 트럭이 출발합니다~!
        truck.startEngine();
        
        // MotorcycleFactory로 오토바이 생성
        VehicleFactory motorcycleFactory = new MotorcycleFactory();
        Vehicle motorcycle = motorcycleFactory.createVehicle();        
        // 출력: 오토바이 출발~!
        motorcycle.startEngine();
    }
}

 

팩토리 메서드 패턴의 주요 목적은 객체 생성에 대한 책임을 서브 클래스, 즉 클라이언트 코드가 아닌 다른 클래스로 분리하여 클라이언트 코드가 구체적인 클래스에 직접 의존하지 않도록 하는 것이다.

 

✨ 장점

클라이언트가 구체 클래스를 직접 언급하지 않고 인터페이스에 의존하여 객체를 생성하므로

1. 구체 클래스를 은닉할 수 있다.

2. 클라이언트와 구체 클래스의 강한 결합을 피할 수 있다.

3. 생성 코드가 한 곳(공장 클래스)에 모여있기 때문에 유지 보수가 용이하다. 수정 및 확장이 용이하다는 뜻인데, 이는 객체 지향 5대 원칙 SOLID 중에 단일 책임 원칙(SRP: Single Responsibility Principle)과 개방 폐쇄 원칙(OCP: Open Close Princlple)에 부합한다. 

객체의 느슨한 결합으로 의존성을 관리하는 생성 패턴으로 관리가 효율적이다. 

 

👎 단점

1. 제품의 수가 증가하면 공장 클래스도 증가하기 때문에 관리가 번거로워질 수 있다. 

2. 클라이언트 코드에서 `new` 연산자를 사용하여 직접 객체를 생성할 때보다 가독성이 떨어질 수 있다. 

 

또한 팩토리 메서드 패턴을 사용하더라도 새로운 클래스가 추가될 때 해당 클래스에 대한 팩토리를 생성해야 하므로, 클라이언트 코드에서 수정이 발생할 수 있다. 예를 들어 Shape 클래스를 상속 받는 클래스 중 `Rectangle` 클래스 대신에 `Triangle` 클래스로부터 객체를 생성하고 싶다면, `ShapeFactory` 클래스를 상속받는 `TriangleFactory` 클래스를 만들고 클라이언트 코드에서 `TriangleFactory` 객체를 생성하여 `Shape` 타입의 `Triangle` 객체를 생성할 수 있다.

 

이 패턴은 객체 생성 로직이나 클래스 구조가 복잡한 경우에 유용하게 사용된다. 

객체 생성 요구 사항이 단순하거나 제품의 수가 제한적인 경우에는 싱글톤과 같은 패턴으로 대체하는 것이 더 효율적일 수 있다.