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

모든 코드는 Swift로 작성되었습니다.

 

 

생성 패턴

생성 패턴이란 GoF 디자인 패턴 중 객체를 생성하는 절차를 추상화하는 5가지 디자인 패턴을 분류한 것을 일컫는 용어이다. 생성 패턴은 현대의 객체 지향 프로그래밍이 상속보다 컴포지션을 사용하는 방향으로 진화하면서 더욱 중요해지고 있다. (실제로 구글에서 개발한 프로그래밍 언어인 Golang 은 아예 상속이란 개념이 존재하지 않는다.)

 

 

📌 상속과 컴포지션

 

상속은 Animal - Cat, Dog 혹은 Man - Son, Husband, BoyFriend와 같이 IS-A 관계일 때 객체의 기능을 코드의 중복 없이 확장시킬 수 있다.

컴포지션은 Computer - Monitor, Keyboard, Mouse와 같이 HAS-A 관계일 때 각각의 객체들을 조합하여 객체의 기능을 확장시킬 수 있다.

 

위에서 소개한 교과서적 예시로는 IS-A 관계와 HAS-A 관계를 명확하게 판단할 수 있지만, 실제 소프트웨어를 개발할 때에는 이러한 관계들에 대한 판단을 하기 쉽지 않다. 예를 들어, HttpResponse라는 객체의 기능을 확장시켜 ClientHttpResponse, ServerHttpResponse라는 객체를 만든다고 생각을 해보자. HttpResponse와 ClientHttpResponse/ServerHttpResponse의 관계가 IS-A 관계인지 HAS-A 관계인지 명확하게 판단할 수 있나?

 

class HttpResponse {}
class Client{}
class Server{}

class ClientHttpResponse: HttpResponse { // 상속
	private var client: Client
}

class ClientHttpResponse { // 컴포지션
	private var client: Client
	private var httpResponse: HttpResponse
}

class ServerHttpResponse: HttpResponse {
	private var server: Server
}

class ServerHttpResponse {
	private var server: Server
	private var httpResponse: HttpResponse
}

 

 

객체 지향 프로그래밍에 대한 지식이 부족한 사람들은 대부분 상속을 사용하여 ClientHttpResponse/ServerHttpResponse 객체를 만들 것이다. 상속은 코드의 중복 없이 효과적으로 기능을 확장시킬 수 있는 강력한 개념인데, 정확한 객체 설계가 이루어지지 않은 상태에서 무턱대고 상속을 사용한다면 객체 간의 결합도가 높아지고 캡슐화를 해칠 수 있는 문제점이 발생한다.

 

따라서, 명확하게 IS-A 관계라고 판단할 수 없는 경우에는 상속보단 컴포지션을 사용하는 것이 더 유리하다.

 

 

팩토리 패턴

팩토리 패턴은 객체의 생성 로직을 추상화하는 생성 패턴의 근간이 되는 패턴이다. 이름에서 알 수 있듯이 여러 객체들을 생성하는 공장 객체를 만들어 사용하는 패턴이다. AnimalFactory라는 공장 객체를 예시를 들어 코드로 확인해 보자.

 

AnimalFactory 객체 코드

enum AnimalType {
  case dog, cat
}

class AnimalFactory { // 공장 객체
  func createAnimal(_ animalType: AnimalType) -> Animal {
    switch animalType {
    case .cat:
      return Cat()
    case .dog:
      return Dog()
    }
  }
}

protocol Animal {
  func speak()
}

class Cat: Animal {
  func speak() {
    print("meow")
  }
}

class Dog: Animal {
  func speak() {
    print("bark!")
  }
}

 

AnimalFactory 객체 사용 예시

class Zoo {
    private var animals = [Animal]()
    private var animalFactory = AnimalFactory()

    func addAnimal(_ animalType: AnimalType) {
        let newAnimal = factory.createAnimal(animalType) // 객체 생성 과정을 추상화
        animals.append(newAnimal)
    }

    func speakAll() {
        animals.forEach { $0.speak() }
    }
}

let zoo = Zoo()

zoo.addAnimal(AnimalType.cat)
zoo.addAnimal(AnimalType.dog)
zoo.speakAll()

 

위 코드에서 확인해 볼 수 있듯이 클라이언트 객체에서 직접 서버 객체의 인스턴스를 생성하는 것이 아니라 팩토리 객체에게 그 작업을 맡긴다. 이에 따라 서버 객체의 생성 로직과 클라이언트 객체의 비즈니스 로직을 분리함으로써 단일 책임 원칙을 준수할 수 있게 되고, 서버 객체 생성 방법을 자세히 알지 않아도 원하는 서버 객체를 요청만 하면 쉽게 받아올 수 있다.

 

 

팩토리 메서드 패턴

팩토리 메서드 패턴에 대해 설명하기 이전에 팩토리 패턴의 문제점부터 알아보자. AnimalFactory 객체의 createAnimal 메서드의 코드에서 객체 생성 과정을 분기 처리 하고 있음을 확인해 볼 수 있다. 분기 처리 코드 같이 경직도가 높은 코드는 개방-폐쇄 원칙을 준수하지 못한다. 즉, Cow라는 Animal 객체가 추가된다면 분기 처리 문을 수정해줘야 한다.

이러한 경직도 높은 코드를 객체 지향 프로그래밍에서는 인터페이스를 활용하여 한번 더 추상화하여 다형성을 이용하는 방식으로 해결한다.

 

팩토리 메서드 패턴이 바로 팩토리 패턴에서 공장 객체를 인터페이스로 한번 더 추상화하여 다형성을 이용하는 디자인 패턴이다.

 

UML 클래스 다이어그램

 

https://yagom.net/courses/design-pattern-in-swift/lessons/생성-패턴/topic/factory-method/

 

• Creator – Factory의 기본 역할을 정의하는 객체
• Concrete Creator – Creator를 채택하고 있으며 Product에 맞는 구체적 기능을 구현
• Product – Concrete Product가 해야 할 동작들을 선언하는 객체
• Concrete Product – Product를 채택하며 그에 맞게 만든 실제 객체

 

코드 예시

Product와 Concrete Prouct

protocol Animal { // Product
  func speak()
}

class Cat: Animal { // Concrete Product
  func speak() {
    print("meow")
  }
}

class Dog: Animal { // Concrete Product
  func speak() {
    print("bark")
  }
}

 

Creator와 Concrete Creator

protocol AnimalFactory {  // Creator
  func createAnimal() -> Animal // 팩토리 메서드 선언
}

class CatCreator: AnimalFactory { // Concrete Creator
  func createAnimal() -> Animal {  // 팩토리 메서드 구현
    return Cat()
  }
}

class DogCreator: AnimalFactory { // Concrete Creator
  func createAnimal() -> Animal { // 팩토리 메서드 구현
    return Dog()
  }
}

 

클라이언트 객체 사용 예시

class Zoo {
  private var animals = [Animal]()

  func addAnimal(creator: AnimalFactory) {
    let newAnimal = creator.createAnimal() // Concrete Creator 사용
    animals.append(newAnimal)
  }

  func speakAll() {
    animals.forEach { $0.speak() }
  }
}

var zoo = Zoo()

zoo.addAnimal(DogCreator())
zoo.addAnimal(CatCreator())
zoo.speakAll()

 

장점

팩토리 패턴 코드와 비교해서 보면 분기 처리문이 사라진 것을 확인해 볼 수 있다. 이에 따라 만약, Cow라는 Animal 객체를 추가하려 할 때, Concrete Product와 Concrete Creator 객체만 하나씩 만들어주면 원래 존재하는 코드를 수정하는 일은 발생하지 않는다. 즉, 개방-폐쇄 원칙을 준수하게 된다.

 

단점

정말 러프하게 말한다면, 분기 처리문을 사용하지 않으려고 Creator를 정의해 주고 Concrete Creator 객체까지 생성해줘야 하기 때문에 배보다 배꼽이 더 커지는 경우가 발생할 수 있다.