[디자인패턴] Factory Method Pattern & Abstract Factory Pattern (팩토리 메서드 패턴 & 추상 팩토리 패턴)

Purpose of Creational patterns (생성 패턴의 목적)

- Allow to creating new objects without explicitly using the new operator.

- 새 연산자를 명시적으로 사용하지 않고 새 개체를 만들 수 있도록 허용

- Factory Method Pattern은 하위 클래스가 실제로 creation을 할지 결정하도록 하는 패턴이기도 함

- Abstract Factory Method Pattern은 객체들을 만드는 인터페이스를 구체적인 클래스에 대해 특정하지 않은 채로 제공 

 

Design Principle (디자인원칙)

- DIP : Dependency Inversion Principle
 → Depend upon abstractions. Do not depend upon concrete classes.

 

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

- factory는 '공장'이란 뜻이고, 공장은 물건을 만드는 곳이다. 여기서 물건에 해당되는 것이 바로 인스턴스!

- factory method 패턴에서는 template method 패턴을 사용하여 인스턴스를 생성하게 됩니다.

- Class-scope pattern / use only inheritance

- Defines an interface for creating an object, but lets subclasses decide which class to instantiate. 

- 개체를 만들기 위한 인터페이스를 정의하지만 하위 클래스에서 인스턴스화 할 클래스를 결정할 수 있습니다. 

→ 초기화를 하위 클래스에 양보하는 형태
→ 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
→ 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고 구체적인 클래스 이름은 뒤로 미루기 때문에, 객체를 생성하는 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 것!

 

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

- abstract factory는 '추상적인 공장'이란 뜻으로, 여러 개의 concrete Product를 추상화 시킨 것! 

- Object-scope pattern  / use composition & delegation

- Provide an interface for creating families of related or dependent objects without specifying their concrete classes

- 구체적인 클래스를 지정하지 않고 관련되거나 종속된 객체의 패밀리를 작성할 수 있는 인터페이스 제공

- Participants :  AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct, Client

→ 인터페이스를 제공해서 다른 객체에게 creation을 위임하는 형태로, 한 단계 더 높은 추상화
→ 여러 개의 concrete Product를 추상화 시키고, 구체적인 구현은 concrete Product class에서 이루어진다. → abstract factory에서는 사용자에게 인터페이스(API)를 제공하고, 인터페이스만 사용해서 부품을 조립하여 만든다. 즉 추상적인 부품을 조합해서 추상적인 제품을 만든다.

=> product를 추가하는 건 cost가 많이 들지만, ConcreteFactory를 추가하는 건 용이함

 

Quiz) Factory Method Pattern을 적용해서 아래 코드를 수정해보세요. (힌트 : product = Database)

public interface Database {}
public class AlphaDatabase implements Database {}
public class DeltaDatabase implements Database {}
public class BadClient {
    public Map queryDatabase(String queryString) {
        Database db = new AlphaDatabase();
        checkQueryIsValid(queryString);
        return db.find(queryString);
    }
}

-> DataBase를 product로 하고, ConcreateProduct class 인 AlphaClient와 DeltaClient가 직접 instantiate 하도록 TemplateClient를 생성해서 interface 연결함

public abstract class TemplateClient {
    public Map queryDatabase(String queryString) {
        Database db = createDatabase ();
        checkQueryIsValid(queryString);
        return db.find(queryString);
    }
    protected abstract Database createDatabase ();
}
public class AlphaClient extends TemplateClient {
    public Database createDatabase () {
        return new AlphaDatabase();
    }
}
public class DeltaClient extends TemplateClient {
    public Database createDatabase () {
        return new DeltaDatabase();
    }
}

 

 

Quiz) 다음 설명과 관련이 있는 설계패턴의 이름을 쓰시오.

• 제품(product)들이 생성(create)되거나 구성(compose), 표현(represent)되는 방식과 무관하게 시스템을 독립적으로 만들고자 한다.
• 여러 제품군(mutiple families of product)중 하나를 선택해서 시스템을 설정할 수 있다.
• 관련된 제품 객체들의 군(family of related product objects)이 함께 사용되도록 설계되었고, 이 제약을 강제하고자 한다.
• 제품들에 대한 클래스 라이브러리(class library)를 제공하고, 그들의 구현(implementation)이 아닌 인터페이스(interface)를 노출하고 싶다.

→ 추상 팩토리(abstract factory) 패턴

 

Quiz) 추상 팩토리(Abstract Factory) 패턴에 등장하는 팩토리 클래스는 도메인 모델(domain model)에서는 나타나지 않고 설계모델에서만 나타난다. 이런 맥락에서, 팩토리 클래스를 만들어내는 설계 결정과 가장 관련성이 깊은 GRASP의 원칙 이름을 쓰고, 해당 원칙을 지키는 경우 어떤 면에서 설계 결과물이 좋아지는지 설명하시오. 

- 원칙 :  Creator Pattern

- 이유 : Abstract Factory 패턴은 구체적인 클래스를 지정하지 않고 관련되거나 종속된 객체의 패밀리를 작성할 수 있는 인터페이스를 제공하는 creation을 위임하는 형태이기 때문에, Low Coupling이 달성됩니다.

 

본 글은 개인의 S/W 구조설계 역량 강화를 위한 학습 목적으로 정리된 내용입니다.
일부 타/개인 단체에 저작권이 있는 자료를 포함하고 있으므로, 절대 영리 목적으로 사용하실 수 없습니다.