팩토리 메서드 패턴 (Factory Method Pattern) 이란?

팩토리 메서드 패턴이란?

객체 생성 패턴의 한 종류이다.
팩토리 패턴은 객체 생성 역할을 별도의 클래스에 넘기는 패턴을 말한다.
객체 생성 책임을 구체적인 클래스가 아닌 추상 메서드에 넘긴다.
- 인터페이스나, 추상 클래스로 구현이 가능하다.
다양한 팩토리 클래스를 만들어 객체 생성 추상 메서드를 구현할 수 있다.

다이어그램으로 살펴보기

Creator 는 factoryMethod() 라는 추상 메서드를 가지고 있다.
- Product 타입의 객체를 반환한다.
- factoryMethod() 는 추상 메서드인만큼 누군가 구현해주어야 한다.
Creator1 은 Creator 의 구현체이다.
- 추상 메서드였던 factoryMethod() 를 구현했다.
Product1 은 Product 의 구현체로 Product 를 상속한다.
Creator1 은 factoryMethod() 에서 Product 의 하위 타입인 Product1 를 반환한다.

현실 세계와의 비유: 자동차 공장

자동차 회사 예제

자동차 회사의 공장에서는 세단을 주문받아 제작할 수 있다.
- CarFactory 클래스에서 buildCar() 메서드를 호출하여 자동차를 만든다.
- CarFactory.buildCar("sedan"); 은 세단을 만드는 코드이다.
자동차 회사의 공장에서는 이제 수요에 맞추어 트럭도 주문받아 만드려고 한다.
- CarFactory.buildCar("truck"); 는 새로이 만들어진 트럭을 만드는 코드이다.

앞으로 자동차 공장에서는 계속 새로운 형태의 자동차를 만들어야 한다. 자동차의 기본 기능은 거의 동일하나 문의 갯수, 좌석의 갯수, 짐받이 여부 는 타입에 따라 달라질 것이다. 어떻게 해야 가장 효율적으로 코드를 작성할 수 있을까?

자바 코드로 살펴보기

`Car`

@AllArgsConstructor
@ToString
public class Car {
    private final String type;
    private final int doors;
    private final int seats;
    private final boolean hasTruckBed; // 트럭 짐칸 여부
}

`CarFactory`

public class CarFactory {
    public static Car buildCar(String type) {
        // validate
        if (type == null) {
            throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
        }

        if(!type.equals("sedan") && !type.equals("truck")) {
            throw new IllegalArgumentException("현재 만들 수 없는 종류의 차입니다.");
        }

        // notifyPreparing
        notifyPreparing(type);

        // produceCar
        Car car = null;

        if(type.equals("sedan")) {
            car = new Car(type, 4, 4, false);
        }

        if(type.equals("truck")) {
            car = new Car(type, 2, 2, true);
        }

        // notifyCompleted
        System.out.println(type + "을 완성했습니다.");

        return car;
    }

    private static void notifyPreparing(String type) {
        System.out.println(type + "을 만들 준비중 입니다.");
    }
}

`Client`

public class Client {
    public static void main(String[] args) {
        Car sedan = CarFactory.buildCar("sedan");
        System.out.println("생산 결과: " + sedan.toString());
        Car truck = CarFactory.buildCar("truck");
        System.out.println("생산 결과: " + truck.toString());
    }
}

위의 코드로도 아직까지 무리없이 세단과 트럭을 만들어낼 수 있다.
그러나 앞으로 공장은 밴, 트레일러, SUV 등 다양한 종류를 만드려고 한다.
- 자동차 종류가 추가되더라도 쉽게 대응하는 방법이 없을까?

공통 부분을 추상화하고 인터페이스로 묶어보기

아무리 타입이 바뀌어도 바뀌지 않는 공통 로직은 어떤 부분일까?
- 검증 부분 (validate)
- 준비 알림 부분 (notifyPreparing)
- 완료 알림 부분 (notifyCompleted)
타입이 바뀔 때마다 변화해야 하는 부분은 어디일까?
- 타입에 따라 커스터마이징 하는 부분 (produceCar)

인터페이스 생성하기

public interface CarFactory {

}

CarFactory 라는 클래스를 전부 지우고 인터페이스로 새로 만들었다.

`validate` 부분 손보기

기존 validate 의 기능은 타입을 확인하여 비었는지, 만들 수 있는 차인지 검증했다.

// validate
if (type == null) {
    throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
}

if(!type.equals("sedan") && !type.equals("truck")) {
    throw new IllegalArgumentException("현재 만들 수 없는 종류의 차입니다.");
}

위와 같이 타입이 한정될 때는 enum 을 활용하면, 잘못된 타입을 입력할 가능성을 없앨 수 있다.
CarType 이라는 enum 클래스를 새로 만들어보자.

public enum CarType {
    SEDAN("sedan"), TRUCK("truck");

    public final String name;

    CarType(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return name;
    }
}

CarType 이라는 enum 클래스를 새로 생성했다.
클라이언트는 더이상 문자열 실수를 하지 않고, 지원하지 않는 타입을 선택할 수도 없다.
CarFactory 인터페이스에서 사용할 공통 validate() 메서드를 생성해보자.

public interface CarFactory {
    private void validateType(CarType type) {
        if (type == null) {
            throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
        }
    }
}

이렇게 인터페이스에 일반 함수를 정의할 수 있게 된 건 자바 11 부터이다.
자바 8 이라면 추상 클래스를 사용해야 한다.

이제는 null 만 체크해주면 된다.

`notifyPreparing()` 과 `notifyComplete()` 생성하기

public interface CarFactory {
    private void validateType(CarType type) {
        if (type == null) {
            throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
        }
    }

    private void notifyPreparing(CarType type) {
        System.out.println(type + "을 만들 준비중 입니다.");
    }

    private void notifyComplete(CarType type) {
        System.out.println(type + "을 완성했습니다.");
    }
}

`buildCar()` 디폴트 메서드 생성하기

public interface CarFactory {
    default Car buildCar(CarType type) {
        validateType(type);
        notifyPreparing(type);
        Car car = produceCar(type);
        notifyComplete(type);
        return car;
    }

    private void validateType(CarType type) {
        if (type == null) {
            throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
        }
    }

    private void notifyPreparing(CarType type) {
        System.out.println(type + "을 만들 준비중 입니다.");
    }

    Car produceCar(CarType type);

    private void notifyComplete(CarType type) {
        System.out.println(type + "을 완성했습니다.");
    }

공통으로 사용될 로직은 전부 의미있는 메서드 이름으로 빠져서 가독성이 매우 좋아졌다.
자동차 종류마다 달라지는 produceCar() 의 구현은 클라이언트에게 넘겼다.
- 팩토리 메서드 패턴의 특징은 객체 생성부 로직 구현을 다른 클래스에 넘기는 것이다.
클라이언트는 공통 로직을 제외한 커스터마이징 로직(produceCar())만 구현하면 되는 것이다.

`MyFactory` 클래스 생성하고, `produceCar()` 메서드 직접 구현해보기

public class MyFactory implements CarFactory {
    @Override
    public Car produceCar(CarType type) {
        // customizing for specific type
        if(type.equals(CarType.SEDAN)) {
            return new Car(type, 4, 4, false);
        }

        if(type.equals(CarType.TRUCK)) {
            return new Car(type, 2, 2, true);
        }

        throw new IllegalArgumentException("생성할 수 없는 종류의 자동차입니다.");
    }
}

MyFactory 클래스를 정의했다.
CarFactory 인터페이스를 상속받은 뒤, produceCar() 메서드를 직접 구현했다.

`Client` 코드 작성하기

public class Client {
    public static void main(String[] args) {
        CarFactory myFactory = new MyFactory();

        Car sedan = myFactory.buildCar(CarType.SEDAN);
        System.out.println("생산 결과: " + sedan.toString());
        Car truck = myFactory.buildCar(CarType.TRUCK);
        System.out.println("생산 결과: " + truck.toString());
    }
}

/*
sedan을 만들 준비중 입니다.
sedan을 완성했습니다.
생산 결과: Car(type=sedan, doors=4, seats=4, hasTruckBed=false)
truck을 만들 준비중 입니다.
truck을 완성했습니다.
생산 결과: Car(type=truck, doors=2, seats=2, hasTruckBed=true)
*/

CarFactory 라는 인터페이스를 구현한 MyFactory 클래스를 이용했다.
기존의 강한 결합에서 인터페이스를 거쳐 결합도가 조금 약해졌다.

코드 추상화하여 조금 더 개선해보기: `Car` 를 상속한 구체적 클래스 만들어보기

조금만 더 코드를 추상화시켜 보기 좋은 코드를 만들어보자.

`produceCar()` 메서드 구현 조금 더 개선해보기

public class MyFactory implements CarFactory {
    @Override
    public Car produceCar(CarType type) {
        // customizing for specific type
        if(type.equals(CarType.SEDAN)) {
            return new Car(type, 4, 4, false);
        }

        if(type.equals(CarType.TRUCK)) {
            return new Car(type, 2, 2, true);
        }

        throw new IllegalArgumentException("생성할 수 없는 종류의 자동차입니다.");
    }
}

new Car(type, 4, 4, false) 이 부분은 '세단을 만든다' 라고 더 축약할 수 있다.
- 모든 세단은 바퀴가 4개고 문짝도 4개이고 전혀 변경될 일이 없다고 가정하자.

`Sedan` 과 `Truck` 클래스 생성하기

public class Sedan extends Car {
    public Sedan() {
        super(CarType.SEDAN, 4, 4, false);
    }
}

public class Truck extends Car {
    public Truck() {
        super(CarType.TRUCK, 2, 2, true);
    }
}

Car 를 상속하여 Sedan 클래스를 생성할 수 있다.
FactoryA, FactoryB, FactoryC 에서 Sedan 이라는 표준을 지켜 자동차를 생산하고 있었는데, 갑자기 모든 세단의 문짝은 앞으로 3개만 만들어야 한다는 법률이 제정된다면?
- new Car(type, 4, 4, false) 이러한 코드를 사용했을 때는 일일이 FactoryA, FactoryB, FactoryC 클래스에 들어가 세단 생성부분을 찾아 각각을 new Car(type, 3, 4, false) 이렇게 변경해주어야 할 것이다.
  - 변경에 취약한 코드임을 반증한다.
- 그러나 Sedan 클래스를 따로 정의해서 썼었다면? Sedan 클래스에 접근하여, 생성자 코드에 있는 doors 숫자를 한번만 변경해주면 된다. super(CarType.SEDAN, 3, 4, false)

만일 `Van` 이 추가된다면?

Van 은 바퀴 4개, 좌석수 12개라고 가정해보자.
짐칸은 없다고 가정한다.

`Van` 추가

public enum CarType {
    SEDAN("sedan"), TRUCK("truck"), VAN("van");
    // ...
}

public class Van extends Car {
    public Van() {
        super(CarType.VAN, 4, 12, false);
    }
}

public class MyFactory implements CarFactory {
    @Override
    public Car produceCar(CarType type) {
        // customizing for specific type
        if(type.equals(CarType.SEDAN)) {
            return new Sedan();
        }

        if(type.equals(CarType.TRUCK)) {
            return new Truck();
        }

        if(type.equals(CarType.VAN)) {
            return new Van();
        }

        throw new IllegalArgumentException("생성할 수 없는 종류의 자동차입니다.");
    }
}

공통 로직은 하나도 건들지 않고 새로운 자동차를 추가했다.
- CarFactory 인터페이스는 전혀 수정할 필요가 없다.
새로운 타입의 자동차를 추가해도 변화하는 영역은 정해져있다.
- 클라이언트 영역과 구체적인 클래스들만 변화한다.
- CarFactory 와 같은 인터페이스는 계속해서 재활용된다.

`HyundaiFactory` 와 `KiaFactory` 가 들어온다면?

새로운 공장이 2개 추가되었다고 가정하자.
현대차와 기아차 공장이 추가되었다.
CarFactory 를 상속하는 두 개의 클래스를 구성하면 된다.
- 현대 차와 기아 차는 타입이 같더라도 각각 다른 이름의 차를 가진다.

현대차 공장과 기아차 공장 추가

@ToString(callSuper = true)
public class Porter extends Truck {
    private final String name = "현대 포터";
}

@ToString(callSuper = true)
public class Sonata extends Sedan {
    private final String name = "현대 쏘나타";
}

@ToString(callSuper = true)
public class Starex extends Van {
    private final String name = "현대 스타렉스";
}


public class HyundaiFactory implements CarFactory {
    @Override
    public Car produceCar(CarType type) {
        if (type.equals(CarType.SEDAN)) {
            return new Sonata();
        }

        if (type.equals(CarType.TRUCK)) {
            return new Porter();
        }

        if (type.equals(CarType.VAN)) {
            return new Starex();
        }

        throw new IllegalArgumentException("생성할 수 없는 종류의 자동차입니다.");
    }
}

public class KiaFactory implements CarFactory {
    @Override
    public Car produceCar(CarType type) {
        if (type.equals(CarType.SEDAN)) {
            return new K5();
        }

        if (type.equals(CarType.TRUCK)) {
            return new Bongo();
        }

        if (type.equals(CarType.VAN)) {
            return new Carnival();
        }

        throw new IllegalArgumentException("생성할 수 없는 종류의 자동차입니다.");
    }
}

이전과 동일하게 한정된 부분만 변화시켜 공장 2개를 신설했다.

클라이언트 코드

public class Client {
    public static void main(String[] args) {
        CarFactory hyundaiFactory = new HyundaiFactory();
        CarFactory kiaFactory = new KiaFactory();

        orderCar(hyundaiFactory, CarType.SEDAN);
        orderCar(hyundaiFactory, CarType.TRUCK);
        orderCar(hyundaiFactory, CarType.VAN);

        orderCar(kiaFactory, CarType.SEDAN);
        orderCar(kiaFactory, CarType.TRUCK);
        orderCar(kiaFactory, CarType.VAN);
    }

    public static void orderCar(CarFactory factory, CarType type) {
        Car sedan = factory.buildCar(type);
        System.out.println("생산 결과: " + sedan.toString());
    }
}

/*
sedan을 만들 준비중 입니다.
sedan을 완성했습니다.
생산 결과: Sonata(super=Car(type=sedan, doors=4, seats=4, hasTruckBed=false), name=현대 쏘나타)
truck을 만들 준비중 입니다.
truck을 완성했습니다.
생산 결과: Porter(super=Car(type=truck, doors=2, seats=2, hasTruckBed=true), name=현대 포터)
van을 만들 준비중 입니다.
van을 완성했습니다.
생산 결과: Starex(super=Car(type=van, doors=4, seats=12, hasTruckBed=false), name=현대 스타렉스)
sedan을 만들 준비중 입니다.
sedan을 완성했습니다.
생산 결과: K5(super=Car(type=sedan, doors=4, seats=4, hasTruckBed=false), name=기아 K5)
truck을 만들 준비중 입니다.
truck을 완성했습니다.
생산 결과: Bongo(super=Car(type=truck, doors=2, seats=2, hasTruckBed=true), name=기아 봉고)
van을 만들 준비중 입니다.
van을 완성했습니다.
생산 결과: Carnival(super=Car(type=van, doors=4, seats=12, hasTruckBed=false), name=기아 카니발)

Process finished with exit code 0
*/

구현체를 생성하는 부분 (변화하는 부분) 을 외부 구현체에 맡겨, 클라이언트에서는 의존성 주입의 형태로 쉽게 차를 주문할 수 있게 되었다.
앞서 살펴봤듯, 객체 생성의 변화에 대응하기 용이한 장점이 있다.
- 객체 생성과 관련된 부분이 변화하더라도 기존 인터페이스의 코드베이스는 전혀 변하지 않는다.

다이어그램 살펴보기

상속 구조가 예쁘게 들어가있다.

첫 코드와 비교해보기

public class CarFactory {
    public static Car buildCar(String type) {
        // validate
        if (type == null) {
            throw new IllegalArgumentException("타입에 null 이 들어올 수 없습니다.");
        }

        if(!type.equals("sedan") && !type.equals("truck")) {
            throw new IllegalArgumentException("현재 만들 수 없는 종류의 차입니다.");
        }

        // notifyPreparing
        notifyPreparing(type);

        // produceCar
        Car car = null;

        if(type.equals("sedan")) {
            car = new Car(type, 4, 4, false);
        }

        if(type.equals("truck")) {
            car = new Car(type, 2, 2, true);
        }

        // notifyCompleted
        System.out.println(type + "을 완성했습니다.");

        return car;
    }

    private static void notifyPreparing(String type) {
        System.out.println(type + "을 만들 준비중 입니다.");
    }
}

만일, 이 코드 스타일을 유지하면서 HyundaiFactory,KiaFactory 를 만들었다면 무슨 일이 일어났을까?
- 모든 Factory 클래스에 코드를 복붙했을 것이다.
- 공통 로직에 대한 변화가 있을 때는 수동으로 전부 바꿔주어야 했을 것이다.
  - 이를테면 notifyComplete 메세지를 바꾸어야 한다면, 모든 클래스를 순회하며 중복된 프린트 코드를 바꾸고 다녀야 한다.

팩토리 메서드 패턴을 배우고 대답해볼만한 질문

팩토리 메서드 패턴을 적용했을 때의 장점과 단점은?
- 장점
  - 확장에 열려있고 변경에 닫혀있게 된다.
    - 인터페이스를 이용해 느슨하게 결합시켰기 때문이다.
  - 생성에 쓰이는 공통 로직을 분류하여 공통화할 수 있다.
    - 중복된 코드가 줄어들게 될 것이다.
    - 상속하는 모든 클래스가 동일한 공통 로직을 사용함을 보장할 수 있다.
  - 생성 객체가 변화할 여지가 있을 때, 변화에 대응하기 좋다.
    - 인터페이스를 상속하는 클래스 하나를 더 만들어 구현만 해주면 된다.
- 단점
  - 많은 클래스 파일과 인터페이스가 생겨난다.
    - 생성 객체가 변화할 여지가 없고 명확할 때는 크게 필요 없을 수 있다.
확장에 열려있고 변경에 닫혀있는 객체 지향 원칙을 설명할 수 있는가?
- 보통 인터페이스를 통해 느슨하게 결합된 경우를 말한다.
- 확장에 열려있다는 것은 변화에 열려있다는 것이다. 새로운 것이 추가되어도 기존의 코드베이스는 수정할 필요 없이 클라이언트 코드만 수정해도 되는 경우를 말한다.
- 변경에 닫혀있다는 것은 새로운 것을 추가하더라도 기존의 코드베이스를 고칠 필요는 없다는 것이다.
자바 8에 추가된 default 메서드에 대해 설명할 수 있는가?
- 인터페이스에서 제공하는 구체적 static method 이다. 자바 8 이전에는 인터페이스 내부에 구체적인 메서드를 작성하는 것이 불가능했었다. 추상 메서드만 정의할 수 있었다.
- 이전과 비교했을 때, 추상 클래스의 필요가 많이 사라졌다. 인터페이스의 활용도가 매우 높아지게 되었다.
- 자바 9에서는 인터페이스에 default method 에 사용하기 위한 private method 도 추가할 수 있게 되었다.

자바 코드베이스에서 찾아보는 팩토리 패턴

자바 코드에서는 실제로 어떻게 팩토리 패턴이 쓰이고 있을까?

`SimpleFactory`

public class SimpleFactory {
    public Object createProduct(String name) {
        if (name.equals("kia_van")) {
            return new Carnival();
        } else if (name.equals("kia_sedan")) {
            return new K5();
        }

        throw new IllegalArgumentException();
    }
}

위는 SimpleFactory 의 기본 예제이다.
인터페이스를 통한 느슨한 결합까지 가지 않고, 조건문을 이용해 간단히 객체 생성 방법을 결정한다.

public class CalendarExample {
    public static void main(String[] args) {
        System.out.println(Calendar.getInstance().getClass()); // class java.util.GregorianCalendar
        System.out.println(Calendar.getInstance(Locale.forLanguageTag("th-TH-x-lvariant-TH")).getClass()); // class sun.util.BuddhistCalendar
        System.out.println(Calendar.getInstance(Locale.forLanguageTag("ja-JP-x-lvariant-JP")).getClass()); // class java.util.JapaneseImperialCalendar
    }
}

Calendar 클래스에서도 SimpleFactory 를 사용한다.
getInstance() 를 뜯어보면 아래와 같은 코드를 찾을 수 있다.

if (cal == null) {
    if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
        cal = new BuddhistCalendar(zone, aLocale);
    } else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja" && aLocale.getCountry() == "JP") {
        cal = new JapaneseImperialCalendar(zone, aLocale);
    } else {
        cal = new GregorianCalendar(zone, aLocale);
    }
}

aLocale 이 가지고 있는 정보에 따라 다른 캘린더를 생성한다.

스프링 `BeanFactory`

public class SpringBeanFactoryExample {
    public static void main(String[] args) {
        BeanFactory xmlFactory = new ClassPathXmlApplicationContext("config.xml");
        String hello = xmlFactory.getBean("hello", String.class);
        System.out.println(hello);

        BeanFactory javaFactory = new AnnotationConfigApplicationContext(Config.class);
        String hi = javaFactory.getBean("hello", String.class);
        System.out.println(hi);
    }
}

BeanFactory 가 Creator 의 역할을 한다.
ClassPathXmlApplicationContext 혹은 AnnotationConfigApplicationContext 는 ConcreteCreator 이다.
getBean() 을 수행할 때, 어떻게 Bean 을 찾아서 가지고 올 것인지에 대한 세부사항이 매우 다르다.
- 팩토리 메서드 패턴의 의도는 이 추상 클래스의 구현을 다른 클래스로 넘겨버리는 것이다.
- ClassPathXmlApplicationContext 는 XML 파일을 이용하도록 구현했을 것이다.
- AnnotationConfigApplicationContext 는 애노테이션을 이용하도록 구현했을 것이다.

레퍼런스

https://www.inflearn.com/course/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4

저작자표시 비영리 (새창열림)

'Java > 자바 디자인 패턴' 카테고리의 다른 글

빌더 패턴 (Builder Pattern) 이란? (0)	2023.01.26
추상 팩토리 패턴 (Abstract Factory Pattern) 이란? (0)	2023.01.24
싱글톤 패턴 (Singleton Pattern) 이란? (0)	2023.01.20
자바 믹스인(mixins)이란? (0)	2021.12.30
제네릭 싱글턴 팩토리 (0)	2021.12.24

팩토리 메서드 패턴이란?

다이어그램으로 살펴보기

현실 세계와의 비유: 자동차 공장

자바 코드로 살펴보기

Car

CarFactory

Client

공통 부분을 추상화하고 인터페이스로 묶어보기

인터페이스 생성하기

validate 부분 손보기

notifyPreparing() 과 notifyComplete() 생성하기

buildCar() 디폴트 메서드 생성하기

MyFactory 클래스 생성하고, produceCar() 메서드 직접 구현해보기

Client 코드 작성하기

코드 추상화하여 조금 더 개선해보기: Car 를 상속한 구체적 클래스 만들어보기

produceCar() 메서드 구현 조금 더 개선해보기

Sedan 과 Truck 클래스 생성하기

만일 Van 이 추가된다면?

Van 추가

HyundaiFactory 와 KiaFactory 가 들어온다면?

현대차 공장과 기아차 공장 추가

클라이언트 코드

다이어그램 살펴보기

첫 코드와 비교해보기

팩토리 메서드 패턴을 배우고 대답해볼만한 질문

자바 코드베이스에서 찾아보는 팩토리 패턴

SimpleFactory

스프링 BeanFactory

레퍼런스

'Java > 자바 디자인 패턴' 카테고리의 다른 글

티스토리툴바

`Car`

`CarFactory`

`Client`

`validate` 부분 손보기

`notifyPreparing()` 과 `notifyComplete()` 생성하기

`buildCar()` 디폴트 메서드 생성하기

`MyFactory` 클래스 생성하고, `produceCar()` 메서드 직접 구현해보기

`Client` 코드 작성하기

코드 추상화하여 조금 더 개선해보기: `Car` 를 상속한 구체적 클래스 만들어보기

`produceCar()` 메서드 구현 조금 더 개선해보기

`Sedan` 과 `Truck` 클래스 생성하기

만일 `Van` 이 추가된다면?

`Van` 추가

`HyundaiFactory` 와 `KiaFactory` 가 들어온다면?

`SimpleFactory`

스프링 `BeanFactory`