[디자인 패턴] Factory Method와 Abstract Factory

Abstract Factory

제품의 군을 생성하기 위한 인터페이스

 

여러 Product Interface들의 조합을 하나의 kit로 이용될 수 있다면 Factory interface에 한 곳에 정의하여 각각의 Product를 Create하는 Concrete Factory(제품군)을 정의할 수 있다.

 

위 그림의 4번째 문장이 단점이 되겠습니다.

생각을 해보면 Factory에서 생성하는 제품들의 기능이 추가되어야 할 때 Interface로 하나의 create abstract function이 생성될텐데 그러면 해당 Factory를 상속받고 있는 모든 제품들이 전부 수정되어야합니다. ( 비용 증가)

 

그래서 우리는 무조건 Abstract Factory Pattern을 이용하면 안되고, 만들고자 하는 Factory의 테마 또는 Kit 종류가 계속해서 늘어날 것이 예상될 때 Abstract Factory Pattern을 이용해야합니다.

위 그림에서 Product가 C, D, E ... 로 늘어난다고 하면 Abstract Factory Pattern을 사용한 것이 완전히 잘못되었습니다.

왜냐하면 ProductC가 생겼다고 한다면 ProductC에 Dependency를 가져야 하는 Client와 ConcreteFactory들이 될텐데 그러면 ConcreteFactory가 많으면 많을수록 cost가 늘어나게 될 것입니다.

참고 :

Dependency는 화살표를 가리키는 방향으로 "Dependency가 있다"라고 표현합니다.

예를 들어

ClassA ----> ClassB 라 할 때 A가 B에 의존적입니다.

따라서 B가 변하면 A에 영향이 갑니다.

하지만 A가 변하더라도 B와는 무관합니다. (B는 A에 의존하지 않습니다.)

 

반대로 ConcreteFactory가 3, 4, 5... 로 늘어난다고 해도 해당 ConcreteFactory에 Dependency가 생기는 모듈은 존재하지 않기 때문에 추가하기가 쉽습니다.

 

이 부분을 이용한 것이 Abstract Factory Pattern 입니다.

 

일반적으로 Factory Method가 이용하기가 쉽기 때문에 처음 구현할 때는 Factory Method로 많이 시작한다. 점차 Requirement가 구체화되고 구조에 대한 파악이 되었을 때 Abstract Factory, Prototype, Buider 등으로 더 flexibility한 구조로 방향을 가져갑니다.

 

Factory 계열의 패턴들은 공통적으로 SOLID Principle 중 DIP를 만족하는 구조입니다.

Factory Method는 Inheritance를 통해 Sub class에서 create object하도록 구현한 방식입니다.

Abstract Factory는 관련성 있는 Product들의 Interface를 하나의 제품으로써 Factory 구조로 만든 것으로 create 역시 factory를 통해서 진행합니다. (object composition과 delegation을 이용)

 

 

마지막으로 Factory Method Pattern에 대한 예시로 확실하게 잡고 넘어갑시다.

Factory Method Pattern의 예시

AlphaDatabase를 직접 new로 객체 생성하는 부분이 거슬렸는데 이 부분을 createDatabase()로 통일시키면 어떤 DB가 추가되더라도 이제 client(creator)는 Dependency가 없습니다. CreateDatabase()는 client(creator)를 상속받는 다른 client에서 구현이 되어야하는 부분이 됩니다. 이것이 Factory Method Pattern 입니다.