JUMPUP - 팩토리 메소드 패턴 (Factory Method)

팩토리 메소드(Factory Method) 또는 팩토리(Factory) 패턴은 객체 생성과 관련된 생성 디자인 패턴이다. 팩토리 패턴에서는 생성 로직을 호출자에게 노출하지 않고 객체를 생성하고 호출자는 동일한 공통 인터페이스를 사용하여 새로운 유형의 객체를 생성하게된다. 이를 통하여 불필요한 의존성을 최소화 할 수 있다.

트럭에 의한 배송만을 지원하는 물류 관리 앱을 개발한다고 생각해보자. 트럭에 의한 배송만을 고려했기 때문에 코드들은 Truck 클래스와 직접적으로 연결되어 있다.  

  

잠시 후 앱이 꽤 유명해지고,  선박에 의한 배송을 추가해달라는 요청이  쇄도하게 된다. 기쁜 소식이지만 기존 대부분의 코드가 Truck 클래스와 연결되어 있어 Ship 클래스를 추가하게 되면 전체 코드를 변경해야 한다. 나중에 또다른 배송 수단을 추가하는 경우 역시 계속해서 전체 코드를 수정해야 하는 문제가 발생하게 된다.

해결책

팩토리 패턴에서 (new 연산자를 사용하는) 직접적인 객체 생성은 특별한 팩토리 메소드 호출로 대체 된다.  

new 연산자를 직접 사용하지 않고 팩토리 메소드을 호출하면 메소드 내부에서 new 연산자를 사용하여 객체를 생성하는 과정이 의미없는 작업으로 생각될 수  있지만  하위 클래스에서 팩토리 메소드를 재정의하여 (기존 코드 수정 없이) 생성되는 객체를 변경할 수 있다. 

이때 하위 클래스에서는 공통된 기본 클래스 또는 인터페이스가 있는 경우에 다른 유형의 객체를 리턴할 수 있다. 또한 팩토리 메소드에서는 이 기본 클래스 또는 인터페이스 형으로 리턴하도록 선언되어 있어야 한다. 

팩토리 패턴은 객체 생성자와 객체를 분리하여 결합도를 낮추는 장점이 있다. 또한 객체 생성 코드를  단일화하여 편리하게 관리할 수 있다. 단점이라면 객체생성을 위한 여러개의 하위클래스를 구현해야 하고 객체 클래스를 인터페이스와 구현으로 분리하여야 한다는 점이다.  

팩토리 패턴의 흔한 예가 바로 DI 기반의 스프링이다. 스프링의 BeanFactory 는 클래스 유형 또는 빈 이름을 인자로 호출하면 해당하는 Bean 을 생성하여 리턴한다. 

정리하면 스프링을 기반으로 하는 경우 별도의 Factory 클래스를 구현하지 않더라도 쉽게 팩토리 메소드 패턴을 구현할 수 있다는 점이다. 

참고자료 

• 『Head First Design Patterns』
• Factory Method