[Design Patterns] Factory Method

 

 

목차

 

 

개요

이번 글에선 Class Creational Pattern인 팩토리 메소드 패턴을 알아보겠습니다.

내용

요약

객체를 생성하는 인터페이스를 만들고, 서브 클래스가 어떤 클래스를 객체화할지 정하자.

동기

 스프링과 같은 프레임워크를 생각해봅시다. 대부분의 프레임워크는 제어의 역전(Inversion of Control) 개념을 사용합니다. 즉, 프레임워크가 애플리케이션의 실행 흐름을 맡고 그 중간중간에 우리는 필요한 코드를 실행시키는 것이죠. 

 예를 들어, 사용자에게 GUI로 여러 문서를 보여주는 프레임워크를 생각해봅시다. 이 프레임워크의 2가지 주요 추상화는 Application, Document가 될 수 있을 것입니다. 두 클래스는 모두 추상 클래스이고, 사용자는 이 클래스의 서브 클래스를 작성해서 자신이 보여줄 문서에 대한 클래스를 작성해야 합니다. 이 때, 프레임워크는 딜레마에 빠집니다. 프레임워크는 사용자가 작성한 서브 클래스를 객체화해야 하지만, 오직 그에 대한 추상 클래스밖에 모릅니다. 즉, 자신이 객체화해야 하는 클래스를 모릅니다. 이 때, 팩토리 메소드가 해결책을 제시합니다.

 

구조

이야깃거리

언제 써야 할까?

• 한 클래스가 자신이 만들어야 하거나 써야 하는 객체의 클래스를 알 수 없을 때

장단점

• (Pros) 사용자는 구체적인 클래스를 코드에 넣을 필요가 없습니다.
• (Cons) 꼭 상속이 필요하지 않을 때라도 불필요한 상속을 해 복잡함을 올릴 수 있습니다.

Case Study

1. Logback

Logback은 로그 설정에 필요한 appender, layout 등 클래스의 커스텀 구현을 할 수 있게 해줍니다. 예를 들어, 사용자가 자신만의 appender를 만들고 싶으면 AppenderBase 추상 클래스를 상속받아 append() 메소드를 오버라이딩하면 됩니다. 그 후, logback 설정 파일에서 작성한 클래스의 경로를 적어주면 logback이 객체화해 사용합니다.

 Logback은 컴파일 시점에 어떤 appender를 객체화해야 하는지 모릅니다. 이 구조를  변형된  팩토리 메소드의 한 예로 볼 수 있을 것 같다. 객체를 생성하는 ConcreteCreator의 역할을 logback 설정 파일과 Creator가 나눠 가진 형태입니다. 

 

출처

GoF's Design Patterns