[Design Pattern] 퍼사드 패턴(Facade Pattern)에 대해 알아보자

Definition

퍼사드 패턴(Facade Pattern)은 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어 줍니다. 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있습니다.

Situation

- 어떤 서브시스템에 속한 일련의 복잡한 클래스를 단순하게 바꿔서 통합한 클래스를 만들어야 한다.

- 클라이언트와 서브시스템이 서로 긴밀하게 연결되지 않아야 한다.

- 복잡한 하위 시스템에 대한 제한적이지만 간단한 인터페이스가 필요한 경우 (Facade는 대부분의 클라이언트 요구 사항에 맞는 하위 시스템의 가장 많이 사용되는 기능에 대한 바로 가기를 제공)

- Subsystem을 레이어로 구성하려는 경우 (Subsystem의 각 레벨에 대한 진입점을 정의)

Structure

Pros

- 하위 시스템의 복잡성에서 코드를 분리할 수 있다.

- 하위 시스템과 클라이언트 간의 약간 결합(low coupling)을 촉진한다.

Cons

- 앱의 모든 클래스에 결합된 God 객체가 될 수 있다.

비슷한 패턴

Decorator -> 인터페이스는 바꾸지 않고 책임(기능)만 추가

 

Facade vs Adapter

Facade는 기존 객체에 대한 새 인터페이스를 정의하는 반면 Adapter는 기존 인터페이스를 사용 가능하게 다른 인터페이스로 변환한다. Adapter는 일반적으로 하나의 객체만 래핑하는 반면 Facade는 객체의 전체 하위 시스템과 함께 작동한다.

 

Abstract Factory는 클라이언트 코드에서 서브시스템 객체가 생성되는 방식만 숨기고 싶을 때 Facade의 대안으로 사용할 수 있다.

 

Flyweight는 많은 작은 객체를 만드는 방법을 보여주는 반면 Facade는 전체 하위 시스템을 나타내는 단일 객체를 만드는 방법을 보여준다.

 

Facade와 Mediator는 비슷한 역할을 한다. 밀접하게 연결된 많은 클래스 간의 협업을 구성하려고 한다.

- Facade는 객체의 하위 시스템에 대한 단순화된 인터페이스를 정의하지만 새로운 기능을 도입하지는 않는다. 하위 시스템 자체는 Facade를 인식하지 못한다. 하위 시스템 내의 객체는 직접 통신할 수 있다.

- Mediator는 시스템 구성 요소 간의 통신을 중앙 집중화한다. 구성 요소는 중재자 객체에 대해서만 알고 직접 통신하지 않는다. 다른 기존 기능을 결합하기 때문에 기능을 추가한다.

대부분의 경우 단일 Facade 객체로 충분하기 때문에 Facade 클래스는 종종 Singleton으로 변환될 수 있다.

 

Facade는 복잡한 엔티티를 버퍼링하고 자체적으로 초기화한다는 점에서 Proxy와 유사하다. Facade와 달리 Proxy는 서비스 객체와 동일한 인터페이스를 가지고 있어 상호 교환이 가능하다.

최소 지식 원칙

Principle of Least Knowledge에 따르면 객체 사이의 상호작용은 될 수 있으면 아주 가까운 '친구' 사이에만 허용하는 편이 좋다. 이 원칙은 보통 다음과 같이 정의할 수 있다.

 

디자인 원칙 -> 진짜 절친에게만 이야기해야 한다.

 

이 원칙을 잘 따르면 여러 클래스가 복잡하게 얽혀 있어서, 시스템의 한 부분을 변경했을 때 다른 부분까지 줄줄이 고쳐야 하는 상황을 미리 방지할 수 있다.