팩토리 패턴(Factory Pattern)

문제점

• 모든 코드에서 원하는 클래스에 대한 객체를 만들 수 있겠지만 이 경우 원하는 클래스가 어떻게 동작하는지, 생성하기 위해 무엇이 필요한지를 클라이언트 코드가 일일이 파악해야 한다.
• 이 경우 다른 클래스에 대한 정보를 구체적으로 알게 된다는 점에서 캡슐화 원칙이 지켜지지 않는다.
• 또한 클라이언트 코드가 클래스에 대한 정보를 가지고 있어야 한다는 부담도 생긴다.

---

 

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

• 클래스의 객체를 만드는 일 자체를 Factory에 위임한다.
• 이 때 클라이언트 코드에서 넘겨주는 조건에 따라 원하는 객체를 반환하는 것이다.
• 팩토리 메서드 패턴에서 조건으로 인한 분기점은 마지막 가장 작은 단위의 클래스를 만드는 시점이 된다.

 

  ex) 라면공장

1. 고객(Client)이 라면공장(RamenFactory)에 신라면(type="신라면")을 만들어달라고 요청한다.
2. 라면공장(RamenFactory)는 고객의 요청에 따라 신라면을 만드는데(createRamen("신라면")) 이 때 만드는 방법(메소드)안에는 면을 만드는 공장(NoodleFactory)과 스프를 만드는 공장(SoupFactory)에 각각 해당하는 면과 스프를 만들어달라고 요청한다.
3. 면공장(NoodleFactory)에서는 해당하는 제조사의 면(Noodle)을 만든다.(createNoodle("신라면"))
4. Noodle 클래스는 인터페이스로 되어 있으며 이는 각각 신라면의 면(ShinNoodle)과 진라면의 면(JinNoodle)으로 구현되어 있다.
5. 요청받은 제조사는 "신라면" 이므로 Noodle에는 ShinNoodle객체를 생성해서 리턴한다.
6. 스프공장(SoupFactory)도 면 공장과 똑같은 인터페이스와 이를 구현하는 클래스들로 이루어져 있다.
7. 고객(Client)는 라면의 제조 과정은 모르지만 조건을 줌으로써 원하는 결과물을 얻을 수 있다.

 

  단점

• 클라이언트의 요청 대상이 되는 Factory에서 너무 많은 구성 클래스들(Factory)들을 만드려고 하면 코드가 길어지고 중복이 많아진다.

---

 

추상 팩토리 패턴(Abstract Factory Pattern)

• 서로 관련이 있는 객체들을 묶어서 한번에 만들어주는 Factory를 만든다.
• 이 Factory들을 만들어주는 Factory를 만드는 것이다.
• 여기서 조건에 따른 분기는 마지막 클래스를 만드는 부분에서 일어나지 않고 Factory를 만드는 Factory에서 조건에 맞는 Factory를 선택하는 시점에서 분기된다.

 

  Ex) 라면공장

1. 고객(Client)는 라면공장의 공장(FactoryOfRamenFactory)에 신라면(type="신라면")을 요청한다.
2. 라면공장의 공장(FactoryOfRamenFactory)에서는 고객의 조건에 일치하는 공장(RamenFactory)에 라면을 만들라고 요청한다.
3. RamenFactory는 인터페이스로서 이는 각각 신라면공장(ShinRamenFactory)와 진라면공장(JinRamenFactory)로 구현되어 있다.
4. 조건이 신라면이므로 신라면공장(ShinRamenFactory)이 선택받아 라면을 만들게 된다.
5. 신라면공장(ShinRamenFactory)는 안에서 면(ShinNoodle)과 스프(ShinSoup)를 만들고 이를 이용한 신라면을 만들어 리턴한다.(각각 Noodle과 Soup를 구현함)
6. 이로써 고객은 라면의 제조과정을 알지 못하고, 관련 있는 클래스들끼리 묶이며, 라면공장의 공장이 생김으로써 추상화가 강화된다.