[디자인패턴] Facade 패턴

Facade의 뜻은 정면, 표면이라는 뜻입니다. 

퍼사드 패턴은 어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공하고, 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용할 수 있습니다.

퍼사드 패턴을 만들기 위해서는 어떤 서브 class에 속한 일련의 복잡한 클래스들을 단순화하고, 통합한 클래스를 만들어야 합니다.

다른 패턴과 달리 추상화같은게 필요없어 단순한 편으로, 퍼사드를 이용하면 클라이언트와 서브시스템이 긴밀하게 연결되지 않아도 되고, 객체지향의 원칙을 준수하는데 도움이 됩니다. 

간단히 말하면 단순화된 인터페이스를 통해 서브시스템을 더 쉽게 사용하게 합니다.

퍼사드 패턴의 장점은 더 간단한 인터페이스를 만들 수 있다는 것이 있습니다. 또한 클라이언트 구현과 서브시스템을 분리할 수 있습니다. 예를 들어 인터페이스가 달라졌을 때 만약 클라이언트를 퍼사드로 만들었다면 클라이언트는 변경할 필요없이 퍼사드만 변경하면 될 것입니다. 

또한 표면에 드러나있는 인터페이스를 사용하고 그 내부는 알 필요가 없게 됩니다.

코드를 통해 이해하면 더 쉬울 것이니 코드를 보겠습니다.

#include <iostream> using namespace std; // 컴퓨터 class Computer { public: void On(void) { cout << "컴퓨터 On" << endl; } void Off(void) { cout << "컴퓨터 Off" << endl; } }; // 모니터 class Monitor { public: void On(void) { cout << "모니터 On" << endl; } void Off(void) { cout << "모니터 Off" << endl; } }; // 스피커 class Speaker { public: void On(void) { cout << "스피커 On" << endl; } void Off(void) { cout << "스피커 Off" << endl; } }; // Facade 패턴 class Facade { private: Computer* m_Computer; Monitor* m_Monitor; Speaker* m_Speaker; public: Facade(Computer* _computer,Monitor* _monitor,Speaker* _speaker) { this->m_Computer = _computer; this->m_Monitor = _monitor; this->m_Speaker = _speaker; } // 컴퓨터 켜기 void PowerOn(void) { cout << "컴퓨터 파워 On" << endl; m_Computer->On(); m_Monitor->On(); m_Speaker->On(); } // 컴퓨터 끄기 void PowerOff(void) { cout << "컴퓨터 파워 Off" << endl; m_Computer->Off(); m_Monitor->Off(); m_Speaker->Off(); } }; int main(void) { Computer computer; Monitor monitor; Speaker speaker; Facade m_ComFacade(&computer,&monitor,&speaker); m_ComFacade.PowerOn(); cout << "==============" << endl; m_ComFacade.PowerOff(); return 0; }

위 코드는 간단한 퍼사드 패턴에 대해 나타내고 있습니다. 

예를 들어, 컴퓨터를 킨다고 할 때, 파워를 누르면 컴퓨터, 모니터, 스피커도 켜져야 합니다. 여러 서브 클래스 일일히 할당해 줄 필요없이 Facade 클래스 하나만 PowerOn() 해주면 그에 따른 서브시스템이 알아서 동작하게 됩니다.

이것이 퍼사드 패턴입니다.

이를 좀 더 유용한 예로 보겠습니다.

#include <iostream> using namespace std; // 애니메이션 class Animation { public: void Play(void) { cout << "애니메이션 Play" << endl; } }; // 카메라 class Camera { public: void Walking(void) { cout << "카메라 Walking" << endl; } }; class Player { private: Camera* m_pCamera; Animation* m_pAnimation; float m_fz; float m_fSpeed; public: // 생성자 Player(Camera* camera,Animation* animation,float fSpeed) { m_fz = 0; this->m_pCamera = camera; this->m_pAnimation = animation; this->m_fSpeed = fSpeed; } void Walking(void) { cout << "플레이어 Walking 시작" << endl; m_fz += m_fSpeed; // 플레이어 좌표가 움직이면 m_pCamera->Walking(); // Camera도 따라서 움직여야 하고, m_pAnimation->Play(); // 걷는 Animation도 나타나야 한다. } }; int main(void) { Camera camera; Animation animation; Player player(&camera,&animation,5.0f); // 플레이어 걷기 player.Walking(); return 0; }

플레이어가 있습니다. 플레이어 움직임에 해당하는 애니메이션 클래스와 카메라 클래스가 있습니다.

플레이어가 움직여 좌표가 변경되면 카메라도 따라서 Walking 해야 합니다.  

위와 같이 짜면 플레이어가 걷는 행동을 하는 것에 대한 애니메이션과 카메라 이동이 어떻게 동작하는지 신경써주지 않아도 된다는 장점이 있습니다. 만약 이렇게 설계하지 않는다면 이동시 마다 애니메이션과 카메라 클래스를 따로 조작해줘야하는 번거로움이 생깁니다.

최소 지식 원칙(= 데메테르의 법칙 Law of Demeter)이라는 것이 있습니다. 

이는 시스템을 디자인할 때, 어떤 객체든 그 객체와 상호작용을 하는 클래스의 개수에 주의해야 하며, 객체들과 어떤식으로 상호작용하는지에도 주의를 기울여야 한다는 뜻입니다. 이것을 이용해 여러 클래스들이 복잡하게 얽혀서 시스템의 한 부분을 변경했을 때 다른 부분까지 고쳐야 되는 상황을 방지할 수 있습니다.

이 원칙을 잘 따르면 객체들 간의 의존성을 줄여 프로그램 관리가 용이해집니다. 하지만 다른 구성요소에 대한 메소드 호출을 처리하기 위해 추가로 클래스를 만들어야 할 수도 있으며 이는 시스템이 더 복잡해지고 개발 시간도 늘어나며 성능도 떨어질 수가 있습니다.

그렇다면 상호작용하는 클래스를 줄이면서 다른 객체에 영향력을 행사하는 방법에는 무엇이 있을까요?

어떤 함수던지 네 종류의 객체의 메소드만 호출하면 됩니다.

1. 객체 자체

2. 메소드에 매개변수로 전달된 객체

3. 그 메소드에서 생성하거나 인스턴스를 만든 객체

4. 그 객체에 속하는 구성요소

위에 따르면 다른 메소드를 호출해서 리턴 받은 객체의 메소드를 호출하는 것도 바람직하지 않습니다. 만약 이럴경우 다른 객체의 일부분에 대해 요청을 하게 되는 것이고, 이러면 직접적으로 알고 지내는 객체의 수가 늘어나게 됩니다. 이때 최소 지식원칙을 따르려면 그 객체 족에서 대신 요청을 하도록 만들어야 합니다.

바로 위 코드를 예로 들면 main 함수는 Player 함수에만 연결되어 있고, Player 함수는 main 함수를 대신해 서브시스템 구성요소를 관리해 줍니다. 따라서 main 이 좀 더 단순하고 유연해 질 수 있습니다.

서브시스템에서도 최소 지식 원칙을 이용해 퍼사드를 추가하면 좀 더 간단한 시스템이 될 수 있습니다.