디자인 패턴 - 구조(Structural)패턴 (4) 퍼사드 패턴(Facade Pattern)

사용하기 복잡한 클래스 라이브러리에 대해 사용하기 편하게 간편한 인터페이스(API)를 구성하기 위한 구조패턴. 

우리가 교제를 보고 필기노트에 재정리를 하듯이 클래스를 재정리하는 행위로 보면 된다.

 

 

Facade: 서브시스템 기능을 편리하게 사용할 수 있도록 하기 위해 여러 시스템과 상호 작용하는 복잡한 로직을 재정리해서 높은 레벨의 인터페이스를 구성한다. Facade 역할은 서브 시스템의 많은 역할에 대해 '단순한 창구'가 된다. 클라이언트와 서브시스템이 서로 긴밀하게 연결되지 않도록 한다.

Additional Facade: 퍼사드 클래스는 반드시 한개만 존재해야 한다는 규칙같은건 없다. 연관되지 않은 기능이 있다면 얼마든지 퍼사드 2세로 분리. 이 퍼사드 2세는 다른 퍼사드에서 사용할 수도 있고 클라이언트에서 직접 접근할 수도 있다. 

SubSystem(하위 시스템): 수십 가지 라이브러리 혹은 클래스들

Client: 서브시스템에 직접 접근하는 대신  Facade를 사용한다.

 

퍼사드 패턴은 전략, 팩토리 패턴과 같은 여타 다른 디자인 패턴과는 다르게 클래스 구조가 정형화 되지 않은 패턴

 

 

재귀적 Facade 패턴 적용 

재귀적 퍼사드란 위에서 언급한 Addtional Facade를 말하는 것이다. 다수의 클래스 다수의 패키지를 포함하고 있는 큰 시스템에 요소 요소 마다 Facade 패턴을 여기 저기 적용하고 다시 그 Facade를 합친 Facade를 만드는 식으로, 퍼사드를 재귀적으로 구성하면 시스템은 보다 편리하게 된다. 이처럼 퍼사드는 한개만 있으라는 법은 없으며 필요에 의해 얼마든지 늘려 의존할 수 있다. 

 

 

사용 시기

시스템이 너무 복잡할때

그래서 간단한 인터페이스를 통해 보갖ㅂ한 시스템을 접근하도록 하고 싶을때

시스템을 사용하고 있는 외부와 결합도가 너무 높을 때 의존성 낮추기 위할때

 

 

장점

 

하위 시스템의 복잡성에서 코드를 분리하여, 외부에서 시스템을 사용하기 쉬워진다.

하위 시스템 간의 의존 관계가 많을 경우 이를 감소시키고 의존서을 한 곳으로 모을 수 있다.

복잡한 코드를 감춤으로써 클라이어트가 시스템의 코드를 모르더라도 Facade 클래스만 이해하고 사용 가능하다.

 

단점

 

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

퍼사드 클래스 자체가 서브시스템에 대한 의존성을 가지게 되어 의존서을 완전히는 피 할 수는 없다. 

추가적인 코드가 늘어나느 것이기 때문에 유지보수 측면에서 고웃가 더 많이 들게 된다.

추상화 하고자하는 시스템이 얼마나 복잡한지 퍼사드 패턴을 통해서 얻게 되는 이점과 추가적인 유지보수 비용을 비교해보며 결정