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

팩토리 메서드 패턴

• 어떤 인스턴스를 생성하는 책임을 구체적인 클래스가 아니라 추상적인 인터페이스의 메서드로 감싸는 패턴
  • 추상화하지 않을 경우 객체지향 SOLID 원칙의 OCP 원칙에 어긋나 변경에 닫혀있지 않음
  • 어떤 인스턴스를 생성하는 책임을 구체적인 클래스(Concrete Class)가 가져가면 구체적인 클래스가 늘어날 때마다 기존 코드 변경이 불가피한 구조
  • 정리하자면 객체 생성의 책임을 서브클래스에게 위임하여, 객체 생성을 위한 인터페이스를 정의하지만 어떤 클래스의 인스턴스를 생성할지는 서브클래스가 결정하게 하는 디자인 패턴

 

https://heidyhe.github.io/factory-method/

 

부연 설명

• 팩토리 역할을 할 인터페이스를 생성하여 구현부 중 일부 변경이 필요한 메서드를 추상 메서드로 선언하고 하위 클래스(Concrete Class)에서 해당 메서드를 구현
• Factory에서 만들어진 Object의 타입이 Product이며 Product 또한 다양하게 만들 수 있도록 인터페이스로 선언
• Factory 안에서 구체적인 인스턴스를 만들게 함으로써 유연한 구조를 가져감 (create)

 

OCP 원칙이란?

• 변경이 닫혀있다는 것은 기존 코드를 변경하지 않으면서 새로운 기능을 확장할 수 있게끔 구조를 만드는 객체지향 원칙
  • 팩토리 메서드 패턴에서 이러한 원칙을 적용했음

 

팩토리 메서드 패턴 구현 예시

• 다음 예시에서는 팩토리 메서드 패턴을 사용하여 Product 객체의 생성 과정을 추상화하였고, 클라이언트 코드는 구체적인 객체 생성 로직에서 분리되었음
• 이를 통해 객체 생성에 대한 유연성과 확장성을 제공할 수 있음

 

1. Product 인터페이스 및 다양한 Product 정의

 

 

2. Factory 인터페이스 및 ConcreteFactory 정의

 

 

3. 팩토리 메서드 패턴을 사용하는 클라이언트 코드 작성

 

 

부연 설명

• 혹자는 새로운 팩토리가 생길 때마다 클라이언트 코드는 바뀌는 것 아니냐고 지적할 수 있음
  • 맞는 지적이지만 클라이언트 코드는 구체적인 팩토리를 알아야 하기 때문에 바뀔 수밖에 없음
  • 하지만 우리가 집중해야 할 부분은 Product와 Creator를 확장할 때 기존 Product와 기존 Factory가 변경되지 않는다는 점을 주목해야 함

 

팩토리 메서드 패턴 장단점

 

장점

• 확장이 열려있고 변경에 닫혀있는 OCP 원칙을 적용해서 기존 코드를 건드리지 않고 새로운 인스턴스를 다른 방법으로 확장 가능
• Product와 Creator 간의 결합을 느슨하게 가져감 (loosely coupled)

 

단점

• 역할을 나누다보니 클래스가 늘어남에 따라 관리 포인트가 늘어남

 

실무에서 쓰이는 팩토리 메서드 패턴

 

1. 단순한 팩토리 패턴

• 매개변수의 값에 따라 혹은 메서드에 따라 각기 다른 인스턴스를 반환하는 단순한 버전의 팩토리 패턴
• ex) java.lang.Calendar

 

 

2. 스프링 BeanFactory

• Object 타입의 Product를 만드는 (스프링의 핵심인 IoC 컨테이너에 해당하는) BeanFactory라는 Creator

 

 

참고

코딩으로 학습하는 GoF의 디자인 패턴 - 백기선 강사님