반응형
Abstract Factory 패턴은 제품군별 객체 생성이 필요할 경우 매우 유용한 패턴이다.
※ 제품군 : 제품 여러 개가 있고, 각 제품들은 또 다시 여러 종류로 나뉠 때 같은 종류의 제품들을 모아놓은 것.
컴파일러를 개발하기 위해 설계를 한다면, 원시코드를 토큰 단위로 잘라주기 위한 스캐너(Scanner), 구문 분석을 하기 위한 파서(Parser), 중간 코드 및 기계어 코드를 생성하기 위한 코드 생성기(Code Generator), 생성된 코드를 최적화시켜주기 위한 최적화 모듈(Optimizer) 등으로 구성된다.
여러 시스템이나 운영체제에서 동일하게 실행이 가능한 컴파일러를 개발 해야 한다면 어떻게 해야하는가?
아래의 클래스 다이어그램은 Abstract Factory 패턴을 사용하여 HP와 Sun환경에서 컴파일러를 설계 했을 때의 설계 구조이다.
Abstract Factory 패턴의 일반적인 클래스 구조는 위와 거의 동일 하다. 먼저 각 클래스 마다 명칭을 알아 보겠다. CompilerFactory 클래스가 AbstracFactory 클래스가 되고, 그 하위 클래스인 HPCompilerFactory 클래스와 SunCompilerFactory 클래스는 ConcreateFactory 클래스가 된다. 그리고 Scanner 클래스와 Parser 클래스 등은 AbstractProduct 클래스가 되고, 그 하위 클래스인 HPScanner, SunScanner, HPParser, SunParser, 등은 Product 클래스가 된다. 그리고 Clinet가 AbstractFactory 클래스와 AbstarctProduct 클래스를 사용하는데 추상 클래스이기 때문에 포인터를 이용한다.
□ Abstract Factory 패턴이 유용한 경우
ㅇ 객체의 생성을 클라이언트(Client)가 직접하는 것이 아니라 간접적으로 수행함으로써 클라이언트가 객체의
생성이나 구성 또는 표현 방식에 독립적이도록 만들고자 할 때.
ㅇ 여러 제품군 중 사용할 제품군을 쉽게 선택 할 수 있도록 만들고 싶을 때.
ㅇ 서로 관련된 제품들이 하나의 제품군을 형성하고, 이런 제품군이 여러 개 존재하는 상황에서 생성되는 제품
객체가 항상 같은 제품군에 속하는 것을 확실히 보장하고 싶을 때.
ㅇ 제품들에 대한 클래스 라이브러리를 만들어야 하는데 그 인터페이스만 드러내고 구현은 숨기고 싶을 때.
이때 각각의 인터페이스는 Abstract Factory 클래스와 제품 종류별 Abstract Base Class(ABC라고 함)에 의해
외부에 드러나며, 구체적인 구현은 하위 클래스에 의해 이루어진다.
□ Abstract Factory 패턴의 장단점
ㅇ 객체가 생성되는 방식이나 과정 및 책임을 클라이언트가 모르도록 만들어준다. 이때 클라이언트는 다만
AbstractFactory 클래스와 AbstractProduct 클래스들의 인터페이스만을 사용하면된다. 이로써 클라이언트
소스코드는 객체가 생성되는 방식이나 과정 및 생성하는 종류가 변경되더라도 그 부분이 국지화될 수 있다.
ㅇ 제품군(HP , Sun, ...)간 교체가 쉽다.
ㅇ 제품군의 개수가 늘어날수록 ConcreateFactory 클래스(HPCompilerFactory, SunCompilerFactory, ...)의
개수도 늘어나야 한다.
ㅇ 제품군에 새로운 제품이 추가되어야 할 경우, 모든 Factory 클래스를 수정해야 한다.
※ 제품군 : 제품 여러 개가 있고, 각 제품들은 또 다시 여러 종류로 나뉠 때 같은 종류의 제품들을 모아놓은 것.
컴파일러를 개발하기 위해 설계를 한다면, 원시코드를 토큰 단위로 잘라주기 위한 스캐너(Scanner), 구문 분석을 하기 위한 파서(Parser), 중간 코드 및 기계어 코드를 생성하기 위한 코드 생성기(Code Generator), 생성된 코드를 최적화시켜주기 위한 최적화 모듈(Optimizer) 등으로 구성된다.
여러 시스템이나 운영체제에서 동일하게 실행이 가능한 컴파일러를 개발 해야 한다면 어떻게 해야하는가?
아래의 클래스 다이어그램은 Abstract Factory 패턴을 사용하여 HP와 Sun환경에서 컴파일러를 설계 했을 때의 설계 구조이다.
Abstract Factory 패턴의 일반적인 클래스 구조는 위와 거의 동일 하다. 먼저 각 클래스 마다 명칭을 알아 보겠다. CompilerFactory 클래스가 AbstracFactory 클래스가 되고, 그 하위 클래스인 HPCompilerFactory 클래스와 SunCompilerFactory 클래스는 ConcreateFactory 클래스가 된다. 그리고 Scanner 클래스와 Parser 클래스 등은 AbstractProduct 클래스가 되고, 그 하위 클래스인 HPScanner, SunScanner, HPParser, SunParser, 등은 Product 클래스가 된다. 그리고 Clinet가 AbstractFactory 클래스와 AbstarctProduct 클래스를 사용하는데 추상 클래스이기 때문에 포인터를 이용한다.
Tip
기울림체는 순수 가상 함수 또는 추상 클래스를 의미한다.
추상 클래스는 하나 이상의 순수 가상 함수를 포함해야 하고, 객체로 존재 할 수 없다.
순수 가상 함수는 함수 구현을 자식 클래스에서 해야 한다는 제약을 준다.
※ 순수 가상 함수를 인터페이스라고 보시면 됩니다. 제가 알기로도 그렇습니다.
하지만 유연히 봤던 하나의 글에서 둘은 어면히 따져서 다르다고 합니다.
그 이유가 기억도 안나고, 어디서 봤는지도 기억이 안나네요.. 결론은 모르겠네요ㅠ
그래서 일단 의문만을 남겨 놓고 넘어갑니다. 그냥 똑같다 였음 좋겠네요ㅎ
기울림체는 순수 가상 함수 또는 추상 클래스를 의미한다.
추상 클래스는 하나 이상의 순수 가상 함수를 포함해야 하고, 객체로 존재 할 수 없다.
순수 가상 함수는 함수 구현을 자식 클래스에서 해야 한다는 제약을 준다.
※ 순수 가상 함수를 인터페이스라고 보시면 됩니다. 제가 알기로도 그렇습니다.
하지만 유연히 봤던 하나의 글에서 둘은 어면히 따져서 다르다고 합니다.
그 이유가 기억도 안나고, 어디서 봤는지도 기억이 안나네요.. 결론은 모르겠네요ㅠ
그래서 일단 의문만을 남겨 놓고 넘어갑니다. 그냥 똑같다 였음 좋겠네요ㅎ
□ Abstract Factory 패턴이 유용한 경우
ㅇ 객체의 생성을 클라이언트(Client)가 직접하는 것이 아니라 간접적으로 수행함으로써 클라이언트가 객체의
생성이나 구성 또는 표현 방식에 독립적이도록 만들고자 할 때.
ㅇ 여러 제품군 중 사용할 제품군을 쉽게 선택 할 수 있도록 만들고 싶을 때.
ㅇ 서로 관련된 제품들이 하나의 제품군을 형성하고, 이런 제품군이 여러 개 존재하는 상황에서 생성되는 제품
객체가 항상 같은 제품군에 속하는 것을 확실히 보장하고 싶을 때.
ㅇ 제품들에 대한 클래스 라이브러리를 만들어야 하는데 그 인터페이스만 드러내고 구현은 숨기고 싶을 때.
이때 각각의 인터페이스는 Abstract Factory 클래스와 제품 종류별 Abstract Base Class(ABC라고 함)에 의해
외부에 드러나며, 구체적인 구현은 하위 클래스에 의해 이루어진다.
□ Abstract Factory 패턴의 장단점
ㅇ 객체가 생성되는 방식이나 과정 및 책임을 클라이언트가 모르도록 만들어준다. 이때 클라이언트는 다만
AbstractFactory 클래스와 AbstractProduct 클래스들의 인터페이스만을 사용하면된다. 이로써 클라이언트
소스코드는 객체가 생성되는 방식이나 과정 및 생성하는 종류가 변경되더라도 그 부분이 국지화될 수 있다.
ㅇ 제품군(HP , Sun, ...)간 교체가 쉽다.
ㅇ 제품군의 개수가 늘어날수록 ConcreateFactory 클래스(HPCompilerFactory, SunCompilerFactory, ...)의
개수도 늘어나야 한다.
ㅇ 제품군에 새로운 제품이 추가되어야 할 경우, 모든 Factory 클래스를 수정해야 한다.
코멘트 (Abstract Factory 패턴과 Factory Method 패턴의 차이)
5장에서 Factory Method 패턴에 대해서 설명을 하는데 Abstract Factory 패턴과 유사함이 많습니다. Abstract Factory 패턴에서도 Factory Method 패턴의 개념이 들어가 있습니다. 대행 함수(CreateScanner, CreateParser, ...)를 통해 객체를 생성하고 있기 때문입니다. 하지만 두 패턴의 차이점이 있습니다. Abstract Factory 패턴은 Client에서 이 대행 함수를 호출 합니다. 하지만 Factory Method 패턴에서는 추상클래스에서 객체를 생성 합니다. 추후에는 각 패턴들의 차이점을 정리해보도록 하겠습니다.
글의 내용은 요점을 정리한 내용이기 때문에 많은 부분이 생략 되었습니다. 자세히 공부하실 분은 책을 구입하셔서 보시기 바랍니다. 이런 책은 갖고 있다면 유용 할 것이라고 생각되네요^^
5장에서 Factory Method 패턴에 대해서 설명을 하는데 Abstract Factory 패턴과 유사함이 많습니다. Abstract Factory 패턴에서도 Factory Method 패턴의 개념이 들어가 있습니다. 대행 함수(CreateScanner, CreateParser, ...)를 통해 객체를 생성하고 있기 때문입니다. 하지만 두 패턴의 차이점이 있습니다. Abstract Factory 패턴은 Client에서 이 대행 함수를 호출 합니다. 하지만 Factory Method 패턴에서는 추상클래스에서 객체를 생성 합니다. 추후에는 각 패턴들의 차이점을 정리해보도록 하겠습니다.
글의 내용은 요점을 정리한 내용이기 때문에 많은 부분이 생략 되었습니다. 자세히 공부하실 분은 책을 구입하셔서 보시기 바랍니다. 이런 책은 갖고 있다면 유용 할 것이라고 생각되네요^^
반응형
'컴퓨터 일반 > 디자인패턴' 카테고리의 다른 글
UML - 클래스 다이어그램 (0) | 2012.04.13 |
---|---|
UML 개요 및 다이어그램 종류 (0) | 2011.12.14 |
4장. Builder 패턴 - 부분 부분 생성을 통한 전체 객체 생성 (0) | 2010.12.10 |
UML (Unified Modeling Language) (2) (0) | 2010.12.04 |
UML (Unified Modeling Language) (1) (0) | 2010.12.04 |
디자인패턴 목차 (0) | 2010.10.27 |