Facade Pattern
-
-
- facade [fəsɑ:d]
퍼사~드
- (건물의) 정면
- (실제와는 다른) 표면, 허울
facade pattern?
일반적으로, 창구를 생각하면 된다.
버스를 예매해보자.
창구와 나의 예매 프로세스
step1.
if (내가 돈을 가지고 있나?) {
나는 갑이다.go > step2
} else {
고속터미널에서 앵벌을 시작하자.
}
step2.
창구 직원에게 "부산 고속 한명이요!"
창구와 나의 예매 프로세스
실제 예매 시스템인 경우 어떤 프로세스로 돌아갈까? 생각해보자.
1. 해당 위치까지 버스가 운행하는지 확인
2. 몇시에 운행하는지 확인
3. 남은 좌석이 몇번이 있는지 확인
extra. 혼자 예매했으니 이놈은 솔로인게 틀림없다. 창가쪽 자리로.
4. 가격이 얼마인지 확인
5. 예매
6. 예매 성공 여부와 함께 거스름돈 반환
나름 복잡하다!!
실제 이것보다..더 많은 체크 리스트가 나온다.
( 도로공사 및 천재지변으로 인한 운행 가능 여부 등)
나는 갑이므로,
창구에서 무슨 일이 일어나는지
알 수도 없고,
알 필요도 없고,
알고 싶지도 않다!!
그럼 어떻게?
의도
서브시스템의 인터페이스들을 통합된 단일 인터페이스로 제공
Facade는 서브시스템을 사용하기 쉽도록 만들어줌
특징
- 퍼사드는 공통적인 작업(tasks)에 대해 편리한 메서드를 가지기 때문에, 더 사용하기 쉽고, 이해하기 쉽고, 테스트하기 쉽게 소프트웨어 라이브러리를 만들 수 있다.
- 같은 이유로 라이브러리를 더 읽기 쉽게 만들 수 있다.
- 대부분의 코드가 퍼사드를 사용하기 때문에, 바깥 코드와 라이브러리 안쪽 코드의 의존성(dependency)을 줄일 수 있고, 따라서 시스템을 개발하는데에 더 유연성을 제공한다.
- 형편없이 설계된 API의 컬렉션을 하나의 잘 설계된 API로 감쌀 수 있다.
문제상황
원하는 건 단지 특정 코드를 컴파일하고 싶은 것임
하지만, 컴파일에 필요한 모든 서브시스템을 알아야 함
해결책
서브시스템을 감춰주는 고수준 인터페이스를 제공
이 인터페이스는 컴파일 기능에 대한 통합 인터페이스를 제공함
적용
복잡한 서브시스템에 대한 간단한 인터페이스르 제공하고 싶을 때
객체 지향 패턴을 적용하다보면 더 작고 더 많은 클래스가 출현
이는 서브 시스템의 재사용/커스터마이징이 더 잘되도록 하지만, 커스터마이징이 필요없는 클라이언트 입장에서 사용을 어렵게 만들기도 함.
Facade는 대부분의 클라이언트에 충분한 서브시스템에 대한 간단한 뷰를 제공한다.
클라이언트와 서브시스템 간의 의존을 줄이고 싶을때
> 서브시스템을 클라이언트에 독립적으로 만들고, 서브시스템의 이식성이 높아짐
서브시스템을 레이어로 구성하길 원할 때
> 각 서브시스템 레벨에 대한 진입점으로 Facade를 정의
메세지흐름
-
클라이언트 > Facade에 요청
-
Facade는 알맞은 서브시스템에 요청 전달
-
(경우에 따라 Facade가 중간에 서브시스템에 맞게 요청을 변경함)
- Facade를 사용하는 클라이언트는 서브시스템 객체에 직접 접근하지 않음
결과
-
클라이언트를 서브시스템 컴포넌트로부터 보호(분리)시킴
-
클라이언트가 협업해야 할 객체수를 줄이고 서브시스템 사용을 쉽게 만들어줌
- 서브시스템과 클라이언트간의 결합을 낮춰줌
- 클라이언트에 영향 없이 서브시스템의 컴포넌트 변경이 가능
- Facade를 통한 레이어 구성은 복잡한/순환 의존을 제거해줌
- 서브시스템 클래스에 대한 직접 접근은 막지 않음
- 따라서, Facade를 통한 쉬운 사용과 직접 접근을 통한 사용(범용성) 사이에서 선택이 가능
구현
-
클라이언트와 서브시스템 감소
- Facade를 추상 클래스로 만들면, 서브시스템 구현 자체를 교체할 수 있음
- 공개/비공개 인터페이스
- 서브시스템은 클래스와 유사
- Facade는 서브시스템의 공개 인터페이스 역할
- Facade로 드러나지 않는 클래스는 외부에 캡슐화 되는 효과
- 서브 시스템의 클래스를 외부에 노출하지 않으면 캡슐화는 더욱 증대