디자인 패턴에서 맨 처음 마주치게 되는 패턴중 하나인 팩토리 메소드 패턴입니다. 객체로 만들 클래스를 애플리케이션에서 명시하지 않아도 되는 장점이 있습니다. 아래 그림을 한번 보죠.
[caption id="" align="aligncenter" width="349" caption="Factory method Pattern from Wikipedia"][/caption]Creator 는 팩토리 역할을 할 ConcreteCreator 의 공통 인터페이스를 정의해 놓은 부모 클래스 입니다. ConcreteCreator는 이것을 상속 받아 factoryMethod() 메소드를 구현하게 됩니다.

간단한  예를 한번 들어볼까요? 아래 pseudo code 를 한번 보지요.
[CODE]
abstract class FruitStore
{
    abstract Fruit   TakeMoneyAndGive(Guest g);
}
[/CODE]
과일가게에 대한 Interface 를 정의해 봤습니다. 가게 주인이 하는 일은 돈을 받고 물건을 건네주는 TakeMoneyAndGive() 라는 메소드가 있네요. 자 이제 과일가게의 ConcreteCreator 에 해당하는 'GuyFruitStore' 을 한번 만들어보지요.

[CODE]
class GuyFruitStore inherits FruitStore
{
    Fruit  TakeMoneyAndGive(Guest g)
    {
        if  g is a girl
            return new GoodFruit
        else
            return new BadFruit
    }
}

class GoodFruit inherits Fruit
{
}

class BadFruit inherits Fruit
{
}
[/CODE]
이 노총각 가게 주인은 동네 아가씨들에게는 달고 맛있는 과일을 주고 그 외의 사람들에게는 싱싱하지 않은 과일을 주네요. 이제 Factory Method 가 어떤 장점을 가지는 지 알아봅시다. '노총각 가게에서 과일을 산다'  라는 문장을 코드로 바꿔보면
[CODE]
// Application code
FruitStore  store =  new GuyFruitStore();
Fruit  f  = store.TakeMoneyAndGive( MySelf );
[/CODE]
과일을 사러 간 본인이 Girl 이라면 f 변수는 GoodFruit 가 될 것이고, 할아버지라면 BadFruit 의 instance 가 저장될 것입니다. 만약 추후에 노총각의 마음씨가 고와져서 귀여운 꼬마의 경우에도 좋은 과일을 주기로 마음 먹었다고 해도, '노총각 가게에서 과일을 산다' 라는 코드는 수정할 필요가 없게 되지요. 수정은 오로지 ConcreteCreator 인 GuyFruitStore 클래스 내에서만 이뤄집니다.
[CODE]
class GuyFruitStore inherits FruitStore
{
    Fruit  TakeMoneyAndGive(Guest g)
    {
        if  g is a girl  or cute kid
            return new GoodFruit
        else
            return new BadFruit
    }
}
[/CODE]

이 처럼 Factory Method pattern 은 객체의 생성을 위임할 수 있어 요구사항 수정에 따른 애플리케이션의 변경을 줄일 수 있다는 장점이 있습니다. 하지만, 과일가게 종류가 늘어날 경우에는 문제가 되지요. 노처녀과일가게, 아줌마과일가게 등이 우후죽순으로 생길 경우는 애플리케이션코드의 수정이 불가피합니다. 이 문제를 해결하기 위해 Factory Method pattern 을 조금 더 추상화한 Abstract factory 라는 패턴이 나오게 됩니다.