팩토리 메소드 패턴 정의:
-> 객체를 생성하기 위한 인터페이스를 정의 하는데 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정한다.
-> 클래스 특성상 생성자를 통하여 객체를 생성하면 그 클래스만의 객체가 생성되는데 이것을 피하기 위하여 직접 각각의 특성을 갖는 클래스를 인터페이스클래스를 상속받아
그 클래스 에서 생성해주는 방식이다.
-> 인터페이스 클래스에서 공통적이거나 연관성있는 메소드를 가상함수로 만들어주고 서브 클래스에서 그 함수를 구현하고, 그타입에 따른 요청을 할때 그 타입의 객체를
생성해준다.
-> 인터페이스 클래스의 포인터를 물고있다가 어떤 타입의 객체인지를 알려주면 그 객체를 생성해준다.
-> 팩토리 메소드 패턴을 이용하면 클래스의인스턴스를 만드는 일을 서브 클래스에게 맏기게 된다.
결론적으로: 인터페이스를 가지는 클래스를 생성하는것이다. 즉 동일한 인터페이스를 준수하는 클래스들을 생성한다.
사용 목적 및 용도, 장점
-> 객체의 생성을 한곳에서 관리 할수있다.
-> 동일한 인터페이스 구현으로 새로운 객체가 추가 되더라도 소스의 수종은 없다,(생성부분의 수정과 신규 클래스의 추가정도만 구현하면 된다.)
-> 객체를 여러군데에서 생성을 각자 하면 ,동일한 생성을 보장 못하지만, 한곳에서 관리하면 동일한 생성을 보장한다.
Ex:
사용자에게 다양한 종류의 문서를 표현할수있는 애플리케이션 프레임 워크가 있다고 가정
이를 위하여서는 두개의 추상화 클래스가 필요함:
1, Application 클래스
2, Document 클래스
이 두 클래스들은 모두 추상 클래스
클라이언트 는 특정 애플리케이션에 종속적인 구현을 위해 새로운 서브 클래스를 정의 할수있다
그리기 관련 어플리케이션을 생성하려면 Drawing-Application 클래스와 Drawing Document 클래스를 정의 해야함
Application 클래스는 Document 를 관리하는 책임을 지니고 있으며 필요에 따라 문서들을 생성하기도 한다.
실제로 Document 의 생성이나 관리는 사용자가 메뉴에서 Open 이나 New 를 선택할때 이루어진다.
각 어플리케이션마다 인스턴스를 만들어야 하는 Document 의 서브 클래스가 다를수 있기 때문에 Application 클래스는 어떤 문서의 인스턴스를 생성해야 하는지를 미리
예측 할수없다.
단지 Application 클래스는 언제 문서의 인스턴스를 만들어야 하는지만 알고 있고,
어떤 종류의 문서를 생성해야 하는지는 알지 못한다.
이경우 문제가 발생
프레임 워크는 클래스를 인스턴스화 해야 하지만, 추상 클래스밖에 모르는 프레임워크는 클래스의 인스턴스화 작업을 수행할수없다.
why? 추상클래스는 인스턴스를 가질수 없기때문이다.
팩토리 메소드 패턴은 이런문제점을 해결함;
Document 의 서브 클래스 중 어느것을 생성해야 하는지는 프레임워크와 분리하여 정의함
Application 클래스의 서브 클래스는 추상화된 CreateDocument() 라는 operation 을 재정의하여 적당한 Document 클래스의 서브 클래스를 반환하도록 한다.
Application 클래스의 서브 클래스가 인스턴스화 되면 애플리케이션에 따른 문서의 인스턴스가 된다.
이때 CreateDocument() operation 을 factory method 라고 하는데 그것은 객체를 만드는 방법을 알고있기 때문이다.