Facade
Structural Pattern
라이브러리, 프레임워크 또는 복잡한 클래스 집합에 대한 간소화된 인터페이스를 제공하는 디자인 패턴
문제
정교한 라이브러리나 프레임워크에 속한 광범위한 코드 집합과 함께 작업해야 할 때 모든 객체들을 초기화하고, 종속성(dependency)를 추적하고, 올바른 순서로 메서드를 실행하려는 노력이 필요합니다.
결국 3rd-party 클래스들과 복잡하게 얽힌 비즈니스 로직이 되어 이해 및 유지관리가 힘들게 됩니다.
해결
facade는 복잡한 서브 시스템에 간단한 인터페이스를 제공하는 클래스입니다. facade 클래스는 하위 시스템과 직접 작업하는 것 보단 제한된 기능을 제공할 수도 있습니다. 클라이언트가 실제로 관심 갖는 기능만 포함합니다.
facade는 수십 개의 기능이 있는 정교한 라이브러리를 사용하지만 그 중 일부의 기능만 필요할 때 편리합니다.
비유
전화 주문을 하기 위해 상점에 전화를 걸면 상담원이 facade가 되어 상점과 각 부서에 대한 기능을 제공합니다. 상담원을 통해 상품 주문, 결제, 배송 서비스 등의 인터페이스를 제공받을 수 있습니다.
구조
- Facade
- 서브 시스템 기능의 특정 부분에 대한 편리한 인터페이스 제공
- 클라이언트 요청에 따른 동작 방법을 알고 있음
- Additional Facade
- 단일 facade가 복잡해지는 것을 방지하기 위해 추가적으로 구현할 수 있음
- 클라이언트와 facade 모두 사용 가능
- Complex Subsystem
- 다양한 객체들로 구성
- 서브 시스템은 facase의 존재를 모름
- Client
- 서브 시스템을 직접 호출하는 대신 facade를 사용
적용 상황
- 복잡한 서브 시스템에 대해 제한적이지만 간편한 인터페이스가 필요한 경우
- 서브 시스템을 계층으로 구성하려는 경우
구현 방법
- 기존 하위 시스템보다 간단한 인터페이스를 제공할 수 있는지 확인
- facade는 하위 시스템을 초기화하고 생명주기를 관리할 책임을 가짐
- 클라이언트는 facade를 통해서만 서브 시스템에 접근하도록 하는 것이 좋음
- 클라이언트 코드는 서브 시스템 코드의 변경으로부터 보호됨
- 서브 시스템이 업데이트 되어도 facade 코드만 수정하면 됨
- 만약 facade가 너무 커진다면 다른 새로운 facade로 분리하기
장단점
✅ 장점
- 하위 시스템의 복잡성으로부터 코드를 분리
❎ 단점
- facade가 앱의 모든 객체와 결합된 객체가 될 수도 있음
참고 링크
Facade
iOS Developer