[펌] AbstractFactory

앞서봤던 FactoryMethod는 하나의 객체를 어떻게 어디서 생성할 것인가에 초점을 뒀다.

AbstractFactorty는 내부적으로 FactoryMethod를 사용하면서 하나의 객체가 아니라,

객체의 군을 생성하는데 초점을 둔다.

즉, FactoryMethod에 하나의 Factory를 덧씌운 패턴이다.

제품군의 예를 들면 스킨이다.

버튼의 예를 들면, 결국 만드는 것은 버튼이지만 스킨에 따라서 모양이 틀리고 이미지가 틀리다.

버튼이 하나의 제품군을 이루는 것이다.

 

조건문을 사용해서 그때마다 맞는 객체를 생성하게 되면 곳곳에 비교 문장이 산재하게 되므로 객체 생성 부분이 흩어여 존재하게 된다.(FactoryMethod와 동일)

이것은 새로운 조건을 추가할 경우 이전 코드와 무관하게 작업할 수 없다는 것이 문제이다.

물론 프로그램 시작 부분에서 객체를 한 번에 생성하고 참조만으로 사용할 수도 있다.

그러나 이것은 미리 객체를 생성해야 한다는 부담이 있고, 한꺼번에 원시 코드를 여러개 컴파일해야 한다는 부담도 있다.

AbstractFactory를 사용해도 물론 수정은 피할 수 없다. 하지만 이 수정이라는 것은 이전 코드와는 독립된 확장이다. AbstractFactory에서는 이러한 가능성을 배제할 수 있게 해 준다.

 

객체 지향 설계의 가장 기본적인 철칙은 변경이 예상되는 부분을 국지화 시킨다는 것을 잊어선 안된다.

 

유용한 경우

1. 객체 생성을 클라이언트가 직접 하지 않고, 간접적으로 수행함으로써, 클라이언트가 객체의 생성 이나 구성에 독립적이도록 만들 때.

2. 여러 제품군 중 사용할 제품군을 쉽게 선택 하도록 만들 때.

 

정리.

1. 객체가 생성되는 방식이나 과정 및 책임을 클라이언트가 모르게 한다. 이때 클라이언트는 AbstractFactory, AbstractProduct의 인터페이스만 알 뿐이다.

2. 제품군의 교체가 쉽다.

->ConcreteFactory 클래스의 객체가 생성되는 부분만 변경하면 된다.

3. 여러 제품군이 섞이는 것을 방지할 수 있다.

->ConcreteFactory 클래스는 특정 제품군만을 생성한다.

4. 제품군이 늘어날 수록 모든 Factory클래스의 수정이 불가피하다.

->ErrorHandler 같은 새로운 제품군이 필요하면 모든 Factory 클래스에 CreateErrorHandler() 메소드를 추가시켜줘야 한다.