생성패턴중 하나로써 동적으로 변환되는 객체들이 그룹으로 이루어져 있을때 팩토리 메소드 객체의 기능을 하는 객체를 한 번 더 추상화해서 추상 팩토리 객체를 만들어 준다. 그런 다음에 팩토리 객체가 반환하는 객체가 하나가 아닌 여러 그룹이 되도록 만든다.
1) 문제 사례 설명
컴파일러를 개발하기 위해 설계를 한다고 생각해보자. 컴파일러는 입력되는 원시 코드를 토큰 단위로 잘라주기 위한 스캐너(Scanner), 구문 분석을 하기 위한 파서(Parser), 중간 코드 및 기계어 코드를 생성하기 위한 코드 생성기(Code Generator), 생성된 코드를 최적화시켜주기 위한 최적화 모듈(Optimizer)등으로 구성된다.
시스템이 서로 다를 경우 기계어 코드를 생성하기 위한 Code Generator 클래스의 구현도 각 시스템마다 달라져야 한다. 각 시스템에 맞추어 CodeGenerator 클래스가 별도로 구현될 가능성이 높다.
뿐만 아니라 컴파일러가 실행될 운영체제환경이 여러 가지일 경우에도 컴파일러를 구성하는 각 클래스들은 운영체제마다 별개로 존재할 가능성이 높다. 구현시 사용하게 될 시스템함수가 각 운영체제마다 다를 수 있기 때문이다. 여기서 문제는 실행될 환경이나 조건이 결정되었다고 할때 어떻게 그 환경이나 조건에 맞는 클래스의 객체만을 생성해서 사용할 수 있을까라는 점이다. 즉 어떻게 같은 제품군에 속한 클래스의 객체만을 생성해서 사용하도록 보장받을 수 있는가하는 점이다.
2) 기본적인 방법 - 조건 비교 방식
조건에 따라 생성하고 사용하는 객체를 달리하는 것이다. 그러나 이런 방법은 시스템이나 운영체제에 맞추어 객체를 생성해야하는 프로그램 곳곳에 조건 비교 문장이 존재하게 됨으로 인해 새로운 조건을 추가할 일이 발생하면 프로그램 전체를 찾아다니며 일일이 수정해야 하는 커다란 문제를 야기할 수 있다.
3) 전담 클래스 활용 방식
객체지향 설계의 가장 핵심적인 접근 방법은 바로 변경이 예상되는 부분을 국지화시킴으로써 변경에 소요되는 비용을 클래스로 최소화하는 것으로 이를 '변경의 국지화'라고 한다.
4) Abstract Factory Pattern 활용
클래스 활용방식에도 여전히 문제점이 존재한다. 소스코드내에 비교 문장이 존재한다는 것이다. 새로운 조건을 추가할 경우 이전 소스코드를 면밀히 분석해서 수정을 해주어야 한다는 점이다. 이는 새로운 조건의 추가를 이전 소스코드와는 무관하게 독립적으로 수행할 수 없다는 사실을 의미한다.
-> 객체지향 설계에서 기존의 것과 독립된 새로운 것을 추가, 확장시키기 위한 가장 좋은 방법중 하나가 클래스 상속을 이용하는 것이다. 객체지향 설계에서 클래스 상속은 크게 두 가지 목적을 가지는데 하나는 상위 클래스는 전반적인 자료형을 대표하면서 외부에 공통된 인터페이스를 제공하고, 하위 클래스들은 각기 다른 구현내용을 가지도록 만들어주기 위한 것이다. 이때 후자의 목적으로 클래스 상속을 이용하게 되면 상속 구조내의 클래스를 사용하는 입장에서는 자료형과 인터페이스는 최상위 클래스를 참조하면서 구체적으로 실행되는 구현내용은 다형성에 따라 결정되도록 만들 수 있다.
-> 제품군을 구성하는 클래스의 객체를 전담 생성하는 클래스를 두되, 새로운 제품군 생성을 추가하는 것이 쉽도록 클래스 상속을 도입하고, 구체적인 제품군별 Factory클래스 상위에 Abstract base Class를 정의한 형태의 설계 구조를 Abstract Factory 패턴이라 한다.
두 가지 문제를 효율적으로 해결할 수 있다. 하나는 개별 제품 클래스의 객체를 생성할때마다 동일한 제품군에 속하는 객체를 생성하기 위해 일일이 조건 검사를 할 필요가 없어졌다는 점이고, 다른 하나는 새로운 제품군을 생성하려고 할 경우 기존 소스코드와는 독립적으로 새로운 제품군을 추가하는 것이 가능하다는 점이다.
5) 구현 소스
(리눅스만 가능;)
Design Pattern
Abstract Factory.cpp