팩토리 메서드(Factory Method) 패턴은 객체를 생성하기 위해 인터페이스에 객체를 생성할 연산을 정의하고, 어떤 클래스의 인스턴스를 생성할지는 그 인터페이스를 상속한 서브 클래스가 결정하도록 하는 패턴이다.
위 그림과 같이 인터페이스(Creator)는 Product 타입을 리턴하는 팩토리 메서드를 정의하고, 다른 메서드(operation)에서 이 팩토리 메서드를 통해 필요한 객체를 생성한다. 어떤 구체 클래스의 인스턴스를 생성할지는 서브 클래스(ConcreteCreator)에게 맡긴다.
위 그림에서는 Creator 클래스를 인터페이스 or 추상 클래스로 정의한 경우의 다이어그램이지만, 경우에 따라 Creator도 추상 클래스가 아닌 구체 클래스로 정의하고 팩토리 메서드는 기본 구현을 제공할 수도 있다.
생성할 객체를 결정하는 책임을 서브 클래스에게 맡기고자 하거나, 자신이 생성해야 할 객체의 클래스를 예측할 수 없을 때 이 패턴을 사용할 수 있다.
이 팩토리 메서드를 사용하는 쪽에서는 Product 인터페이스로 객체를 사용하도록 한다.(operation 메서드) 애플리케이션은 Product 인터페이스에 정의된 연산만 사용하도록 구현하면, 어떤 서브 클래스(ConcreteCreator)라도 사용할 수 있다.
이 패턴을 사용하여 객체를 직접 생성하여 특정 클래스에 종속되는 것을 피하고, 이를 서브 클래스에게 맡김으로써 훨씬 유연하게 코드를 작성할 수 있다.
이 패턴을 사용함에 있어서 주의할 점은, 부모인 Creator의 생성자에서 팩토리 메서드를 호출하면 안된다. 부모 생성자가 동작할 때는 서브 클래스가 구현을 담당하는 팩토리 메서드를 사용할 수 있는 상황이 아니기 때문이다. 간단한 이유로 서브 클래스에서 구현하는 이 팩토리 메서드가 서브 클래스의 필드에 의존해서 객체를 생성할 수도 있다. 이 패턴을 사용할 때는 상속을 고려해야 한다.
추상 팩토리 패턴은 이 팩토리 메서드를 이용해서 구현할 때가 많다. 추상 팩토리 클래스에서 필요한 객체를 구체 팩토리 클래스에서 얻어올 때도 있기 때문이다. 또한 템플릿 메서드 패턴을 이용하여 구현할 때, 템플릿에 해당하는 메서드에서 필요한 객체를 서브 클래스 팩토리 메서드로 얻어올 때도 있다.
팩토리 메서드의 단점은 생성할 인스턴스의 클래스가 변경될 때마다, 새로운 서브 클래스를 만들어야 한다는 점이다.