팩토리 메서드 패턴(Factory Method Pattern)
객체 생성을 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성하게 하는 생성 디자인 패턴
ㅡ> 클라이언트에서 직접 new 연산자로 객체를 생성하지 않고, 제품 객체의 생성을 도맡아 하는 공장 클래스를 만들고 이를 상속하는 서브 공장 클래스의 메서드에서는 여러가지 제품 객체 생성을 각각 책임지는 형태
+ 객체 생성에 필요한 과정을 템플릿처럼 미리 구성해놓고 객체 생성에 관한 전처리, 후처리를 통해 생성 과정을 다양하게 처리해 객체를 유연하게 결정할 수 있음
ㅡ> 객체간의 결합도를 낮춰 유지보수의 효율성 향상
팩토리 메서드 패턴 구조
- Dialog : 최상위 공장 클래스 ㅡ> 팩토리 메서드를 추상화하여 서브 클래스에서 객체를 생성하도록 함
- 객체 생성 처리 메서드(render) : 객체 생성에 관한 전처리, 후처리를 템플릿화한 메서드
- 팩토리 메서드(createButton) : 서브 공장 클래스에서 재정의할 객체 생성 추상 메서드
- WindowsDialog, WebDialog : 서브 공장 클래스 ㅡ> 해당하는 제품 객체를 반환하도록 생성 추상 메서드를 재정의하여 제품 객체 하나당 그에 맞는 생상 공장 객체가 위치
- Button : 제품 구현체 추상화
- Windows, HTML Button : 제품 구현체
코드 예제
using namespace std;
class Button{ //구현체 인터페이스
public:
virtual ~Dialog(){}
virtual string render() const = 0;
};
class WindowsButton : public Button{ //구현체 1
public:
string render() const override {
return "WindowsButton";
}
};
class HTMLButton : public Button{ //구현체 2
public:
string render() const override {
return "HTMLButton";
}
};
class Dialog{ //공장 클래스
public:
virtual ~Dialog(){};
virtual Button* createButton() const = 0; //팩토리 메서드
string render() const{
Button* button=this->createButton(); //구현체 생성(팩토리 메서드 이용)
string result=button->render(); //구현체 이용
delete Button;
return result;
}
};
class WindowsDialog : public Dialog{ //서브 공장 클래스 1
public:
Button* createButton() const override {
return new WindowsButton;
}
};
class HTMLDialog : public Dialog{
public:
Button* createButton() const override { //서브 공장 클래스 1
return new HTMLButton;
}
};
팩토리 메서드를 적용해 작성된 Button이라는 구현체에 대한 코드입니다. Button 클래스가 구현체 인터페이스에 해당하며 이를 이용하는 Dialog 클래스가 공장 클래스입니다. Dialog를 상속 받는 서브 공장 클래스인 WindowsDialog, HTMLDialog가 각기 팩토리 메서드인 createButton을 override하여 알맞은 Button(구현체)를 생성하여 반환하고 이를 이용하여 Dialog에서 동작을 수행하게 되면 구현체에 override된 함수에 따라 알맞은 동작을 수행합니다.
팩토리 메서드 패턴의 특징
패턴 사용 시기
- 클래스 생성과 사용의 처리 로직을 분리 ㅡ> 결합도를 낮추고자 할 때
- 코드가 동작해야 하는 객체의 유형과 종속성을 캡슐화를 통해 정보 은닉 처리할 경우
- 라이브러리 혹은 프레임워크 사용자에게 구성 요소를 확장하는 수단을 제공하려는 경우
- 기존 객체를 재구성하는 대신 기존 객체를 재사용하여 리소스를 절약하고자 할 경우
패턴 장점
- 생성자(공장 클래스)와 구현체의 강한 결합을 피할 수 있음
- 팩토리 메서드를 통해 객체의 생성 후 공통으로 수행하는 기능을 지정 가능
- 캡슐화, 추상화를 통해 생성되는 객체의 구체적인 타입 은닉 가능
- SRP(단일 책임 원칙) 준수 : 객체 생성 코드를 한 곳(클래스)에 한정하여 코드를 유지보수가 용이함
- OCP(개방 폐쇄 원칙) 준수 : 기존 코드를 수정하지 않고 새로운 종류의 제품을 추가 가능 (확장이 쉬움)
- 생성에 대한 인터페이스 부분과 생성에 대한 구현 부분이 분리되어 있어 패키지 분리하여 개별로 여러 개발자가 협업하기 용이함
패턴 단점
- 각 제품 구현체마다 팩토리 객체들을 모두 구현해주어야 한다 ㅡ> 구현체가 늘어날 때마다 팩토리 클래스가 증가 ㅡ> 서브 클래스 수가 폭발적으로 증가
- 코드의 복잡성 증가
* 팩토리 메서드 vs 템플릿 메서드
팩토리 메서드는 템플릿 메서드의 특수화이다
팩토리 메서드 패턴 | 템플릿 메서드 패턴 | |
공통점 | 추상 메서드를 정의하고 서브 클래스가 추상 메서드를 구현화 템플릿화 된 메서드에서 로직을 공통화 하기도 함 |
|
차이점 | 구현할 대상 : 객체 생성 알고리즘 | 구현할 대상 : 실행할 전략 알고리즘 |
참고자료
https://refactoring.guru/ko/design-patterns/factory-method
팩토리 메서드 패턴
/ 디자인 패턴들 / 생성 패턴 팩토리 메서드 패턴 다음 이름으로도 불립니다: 가상 생성자, Factory Method 의도 팩토리 메서드는 부모 클래스에서 객체들을 생성할 수 있는 인터페이스를 제공하지
refactoring.guru
💠 팩토리 메서드(Factory Method) 패턴 - 완벽 마스터하기
Factory Method Pattern 팩토리 메소드 패턴은 객체 생성을 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성하게 하는 생성 디자인 패턴이다. 즉, 클라이언트에서 직접 new 연산자를 통해 제품 객체를
inpa.tistory.com
'OOP' 카테고리의 다른 글
[OOP] 추상 팩토리 패턴(Abstract Factory Pattern) (0) | 2025.01.21 |
---|---|
[OOP] 싱글톤 패턴(Singleton Pattern) (0) | 2025.01.16 |
[OOP] 디자인 패턴(Design Pattern) (0) | 2025.01.14 |
[OOP] 객체 지향 설계 5원칙(SOLID) : DIP(Dependency Inversion Principle)-의존 역전 원칙 (0) | 2025.01.13 |
[OOP] 객체 지향 설계 5원칙(SOLID) : ISP(Interface Segregation Principle)-인터페이스 분리 원칙 (1) | 2025.01.10 |