객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스에서 책임지도록 한다.
유용한 경우
- 구체적으로 어떤 클래스의 객체를 생성해야 할지 미리 알지못하는 경우
- 객체의 종류별로 객체 생성과 관련된 부분을 국지화 시키는 경우
장점
- 어떤 객체를 생성할 것인지와는 무관하게 동일한 형태로 프로그래밍이 가능하다.
; 당연하다. 클래스 상속을 통한 다형성을 구현하므로 ...
- 클라이언트가 직접 객체를 생성하는 것보다 유연한 확장성 구조를 가지게 된다.
; 새로운 객체를 생성하거나 이전 객체를 확장해서 생성하고자 할 때
새로운 하위 클래스를 정의하고 Factory Method에 해당하는 멤버 함수만
Override 시키면 된다.
; 다시 말하자면 객체 생성과 관련된 변경을 국지화 시킬 수 있다.
- 서로 연관된 클래스들의 상속관계가 병렬로 존재하는 경우 한 쪽 상속 관계의
클래스들이 다른 쪽 상속 관계의 클래스 객체를 생성할 때 유용하다.
- 상속관계에 있는 클래스들의 멤버 함수가 동일한 프로그램 로직을 가지고 있으면서
내부적으로 생성할 객체만 서로 다를 때 편리하다.
; 로직은 상위클래스에서 구현하고 생성과 관련된 부분만 하위 클래스에서 구현한다.
단점
- 객체의 종류가 달라질 때마다 새로운 하위 클래스를 정의해야한다.
; 따라서 불필요하게 많은 클래스들을 내포할 가능성이 있다.
[뱀발바닥]
패턴의 유용성을 알리기 위해 좀 어거지라고 생각되는 예를 (지극히 내생각이다.) 들었다는 느낌이 많이 들었다. GoF 패턴에 대한 해설서이므로 저자가 의도적으로 설명하기 위해서 그렇게 한 것 같긴 하지만 나에겐 좀 아쉬운 부분이다. 하지만 아직 이쪽부분에 대해 용어나 표현에 대해 미숙하기 때문에 그렇게 생각하는지도 모르겠다. 어쨌든 패턴이라고 하는 영역이 소프트웨어를 설계할 때 많은 도움이 되리라고 확신하지만 너무 이쪽 이론에 빠지게 되면 자칫 말장난에 빠질 수도 있겠다는 생각이 든다. 패턴은 객체지향언어를 제대로 쓰기 위해 필요한 기본적인 테크닉일 뿐이라고 생각한다. 나머지는 자신의 영역에 맞게 적용하는게 문제라고 본다. 뭐 그게 어렵겠지만 ㅋㅋㅋ
