디자인 패턴 총정리 시리즈의 두 번째 패턴은 Factory Method Pattern입니다.
이것도 singleton pattern과 마찬가지로 실제로 작업할 때 많이 사용했던 패턴입니다.
1. 개요
Factory Method Pattern은 생성패턴 중 하나입니다. 기본 클래스에 추상 메서드를 도입해서 하위 클래스가 만들 객체 인스턴스를 결정할 수 있습니다. 해당 패턴은 코드의 유연성과 확장성, Client 클래스와 Concrete 클래스 간의 decoupling을 하는데 도움이 됩니다.
2. 예시 - Vehicle Factory
차량 공장에서 자동차와 오토바이와 같은 다양한 유형의 차량을 만드는 시나리오를 예로 들어보겠습니다.
다음은 C++ 구현 예시입니다.
// Abstract base class for vehicles
class Vehicle {
public:
virtual void drive() = 0;
};
// Concrete vehicle classes
class Car : public Vehicle {
public:
void drive() override {
std::cout << "Driving a car." << std::endl;
}
};
class Motorcycle : public Vehicle {
public:
void drive() override {
std::cout << "Driving a motorcycle." << std::endl;
}
};
// Vehicle Factory
class VehicleFactory {
public:
virtual Vehicle* createVehicle() = 0;
};
// Concrete vehicle factory classes
class CarFactory : public VehicleFactory {
public:
Vehicle* createVehicle() override {
return new Car();
}
};
class MotorcycleFactory : public VehicleFactory {
public:
Vehicle* createVehicle() override {
return new Motorcycle();
}
};
위의 코드에서 abstract base class인 Vehicle과 concrete vehicle classs인 Car와 Motorcycle을 정의합니다.
VehicleFactory 클래스는 createVehicle은 반환값으로 Vehicle 객체 포인터를 가집니다. VehicleFactory를 상속받은 Concrete vehicle factory class들은 createVehicle을 오버라이딩 해서 concrete vehicle classs를 반환해 줄 수 있습니다.
아래와 같은 클래스 다이어그램에 위의 예시를 맞춰서 생각해 보시면 좋을 것 같습니다.
3. 장점
1) Flexible object creation: Factory Method Pattern을 사용하면 client가 구체적인 유형을 지정하지 않고 객체를 생성할 수 있어 코드의 유연성을 높이고 특정 클래스에 대한 의존도를 줄일 수 있습니다.
2) Encapsulation of object creation: 객체를 생성하는 logic이 factory class 안으로 캡슐화되기 때문에, 객체 인스턴스를 관리할 수 있는 장소를 집중할 수 있습니다.
3) Code extensibility: 새로운 Concrete factory를 도입하는 방식이 간단하고, 기존 client 코드를 수정하지 않고 product를 새롭게 수정할 수 있습니다.
4. 단점
1) Increased complexity: Factory Method Pattern은 코드 복잡도를 증가시킬 수 있고, 잠재적으로 코드 가독성에 영향을 줄 수 있습니다.
2) Maintenance overhead: 새롭게 product 변형을 해야 할 경우, 해당 product들과 일치하는 concrete class와 관련된 factory 요소들을 생성해야 하므로 유지보수 비용이 높아질 수 있습니다.
5. 결론
Factory Method Pattern은 객체 생성에 대한 구조화된 접근 방식을 제공합니다. 위의 예시였던 차량 공장과 같은 Factory Method Pattern 구조를 활용하여 유연하고 분리된 객체 인스턴스 생성 로직을 만들 수 있습니다.
그러나 코드 복장성과 유지 관리 비용 증가 등의 단점을 가질 수 있기 때문에 과한 사용은 지양하는 것이 좋습니다.
실제로 사용했을 때는 통신 모듈 클래스를 생성할 때 많이 사용했던 기억이 납니다.
통신 모듈은 대부분 send, receive, open, close 등과 같은 메서드를 공유하기 때문에 유용했습니다.
추상화할 때 굉장히 편리하지만 억지로 코드 분리나 캡슐화, 은닉 등을 위해 쓰는 것은 추천하지 않습니다.
'Study > Software Architecture' 카테고리의 다른 글
[디자인패턴] 생성패턴(5) - Prototype Pattern (프로토타입 패턴) (0) | 2023.05.19 |
---|---|
[디자인패턴] 생성패턴(4) - Builder Pattern (빌더 패턴) (0) | 2023.05.18 |
[디자인패턴] 생성패턴(3) - Abstract Factory Pattern (추상 팩토리 패턴) (0) | 2023.05.18 |
[디자인패턴] 생성패턴(1) - Singleton Pattern (싱클턴 패턴) (0) | 2023.05.14 |
[디자인패턴] GOF (Gang Of Four)의 23가지 디자인 패턴 장단점 총정리 (0) | 2023.05.14 |