[디자인 패턴] 팩토리 메서드 패턴

객체 생성을 캡슐화 하여 ‘팩토리 클래스’를 통해 생성하도록 하는 생성 디자인 패턴

 

구조

• Creator
  • Product 객체를 생성하는 메서드 정의 (protocol / class)
• Concrete Creator
  • Concrete Product를 생성하기 위한 구체화 된 메서드를 가진 객체
• Product
  • Creator을 통해 생성될 수 있는 객체의 추상화 된 공통 Interface 선언 (protocol)
• Concrete Product:
  • Product에서 선언된 Interface가 구체화 된 실제 객체
    
    
    

출처:  https://www.pentalog.com/blog/design-patterns/factory-method-design-pattern/

 

 

---

Swift 예제 코드

// Product
protocol Bread {
    var name: String { get }
}

// Concrete Product
struct CreamBread: Bread {
    var name: String = "크림빵"
}

struct SoboruBread: Bread {
    var name: String = "소보루빵"
}

// Creator
protocol BreadCreator {
    associatedtype Product: Bread
    
    func make() -> Product
}

// Concrete Creator
final class CreamBreadCreator: BreadCreator {
    typealias Product = CreamBread
    
    func make() -> CreamBread {
        CreamBread()
    }
}

// Concrete Creator
final class SoboruBreadCreator: BreadCreator {
    typealias Product = SoboruBread
    
    func make() -> SoboruBread {
        SoboruBread()
    }
}

 

---

언제 사용하면 좋을까?

💡 객체 생성 과정을 추상화하여 코드의 유연성과 확장성을 높이는 데 큰 장점이 있다.

 

• “다양한 구현체가 필요할 때” 음악 재생 앱에서 다양한 형태의 음악 파일을 재생해야 할 경우, 각 파일 형식에 맞는 재생기를 생성하는 데 팩토리 메서드 패턴을 사용하면 유연성이 높아질 수 있다.
• “확장성이 중요한 경우” 애플리케이션의 요구 사항이 변경되어 새로운 객체 타입을 추가해야 할 때, 팩토리 메서드를 사용하면 기존 코드를 수정하지 않고도 새로운 클래스를 쉽게 추가할 수 있다.
• “객체 생성 로직을 숨기고 싶을 때” 객체 생성에 복잡한 로직이나 조건이 필요한 경우, 이를 클라이언트로부터 숨기고 싶을 때 유용하다.

 

주의 할 점

• “객체 생성 메서드의 다수 필요” 각 객체를 위한 팩토리 메서드를 각각 제공해야 합니다. 이는 단일 팩토리 클래스가 많은 수의 팩토리 메서드를 포함하게 되어, 클래스의 복잡도가 증가할 수 있다.
• “코드의 복잡성 증가” 간단한 객체 생성에 팩토리 패턴을 적용할 경우, 오히려 코드의 이해와 유지보수를 어렵게 만들 수 있다.
• “투머치 확장성과 유연성” 팩토리 패턴은 확장성과 유연성을 제공하지만, 때때로 이를 과도하게 추구하다 보면, 실제 필요 이상으로 복잡한 구조를 만들어낼 위험이 있다.