1. 용도
한 서브시스템 내의 인터페이스 집합에 대한 획일화된 하나의 인터페이스를 제공하는 패턴으로, 서브시스템을 사용하기 쉽도록 상위 수준의 인터페이스를 정의합니다.
2. 활용성
- 복잡한 서브시스템에 대한 단순한 인터페이스 제공이 필요할 때
- 추상 개념에 대한 구현 클래스와 사용자 사이에 너무 많은 종속성이 존재할 때
- 서브시스템을 계층화시킬 때
3. Class Diagram과 구조
[Facade] - 단순하고 일관된 통합 인터페이스를 제공하며, 서브시스템을 구성하는 어떤 클래스가 어떤 요청을 처리해야 하는지 알고 있으며, 사용자의 요청을 해당 서브시스템 객체에 전달합니다.
[SubSystems] - 서브시스템의 기능을 구현하고, Facade 객체로 할당된 작업을 실제로 처리하지만 Facade에 대한 아무런 정보도 없습니다.
사용자는 Facade에 정의된 인터페이스를 이용해서 서브시스템과 상호작용 합니다. Facade는 해당 요청을 서브시스템을 구성하는 적당한 객체에게 전달하고 서브시스템을 구성하는 객체가 실제의 요청 처리를 담당하지만 Facade는 이를 전달하기 위해 인터페이스에 동일한 작업을 정의해야 합니다.
4. 장단점
장점
- 서브시스템의 구성요소를 보호- 복잡한 객체를 구성하는 요소에 속한 연산을 새로운 방문자를 추가하여 쉽게 추가할 수 있습니다.
- 서브시스템과 사용자 코드 간의 결합도 약화 - 방문자가 객체 구조 내 각 원소들을 방문하면서 상태를 누적가능합니다. 이가 없다면, 전역 변수로 존재해야 하거나 다른 연산이 할당되어야 합니다.
- 응용프로그램 쪽에서 서브시스템 클래스를 사용하는 것을 완전히 막지는 않습니다. 그러므로 Facade를 사용할지 서브시스템 클래스를 직접 사용할지 결정할 수 있습니다.
5. 구현 방법
- 사용자와 서브시스템 간의 결합도 줄이기- 사용자와 서브시스템 간의 의존성을 줄이는 방법은 Facade를 추상 클래스로 정의하고, 서브시스템을 나타내기 위해 이를 상속하는 구체 서브클래스를 정의하여 다른 구현을 정의하도록 하는 것입니다. 그러면 사용자는 Facade만 사용하기 때문에, 어떤 서브시스템의 구현이 사용되고 있는지 알 필요가 없게 됩니다.
- 서브시스템 클래스 중 공개할 것과 감출 것 - 서브시스템은 클래스와 유사합니다. 클래스의 인터페이스를 정의할 때 공개할지 말지를 고민하는 것처럼 서브시스템의 인터페이스도 공개할지 말지를 생각해 봐야 합니다.
'C++공부 > GoF의 디자인 패턴' 카테고리의 다른 글
| 프록시(Proxy) (0) | 2022.07.06 |
|---|---|
| 플라이급(Flyweight) (0) | 2022.07.06 |
| 장식자(Decorator) (0) | 2022.07.06 |
| 복합체(Composition) (0) | 2022.07.06 |
| 가교(Bridge) (0) | 2022.07.06 |