[디자인 패턴] 7.(2) 퍼사드 패턴 (Facade Pattern)
이 글은 헤드퍼스트 디자인패턴과 GoF 디자인패턴을 읽고 정리한 글입니다.
1. 퍼사드 패턴(Facade Pattern)
퍼사드 패턴은 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어줍니다. 또한 고수준 인터페이스를 정의하여 서브시스템을 더 편리하게 사용할 수 있습니다.
1.1. 구성 요소
Facade
- 요청에 대하여 어떤 subsystem이 적절히 처리할 수 있는지에 대해 알고 있습니다.
- 클라이언트의 요청에 대한 처리를 적절한 subsystem 객체에 위임합니다.
subsystem classes
- 실제로 시스템에서 처리할 기능이 구현된 컴포넌트입니다.
- Facade 에 의하여 작업을 할당받습니다, 하지만 Facade 에 대하여서는 알고있지 않습니다(참조가 없음).
1.2. 적용 방법
- 복잡하고 여러 컴포넌트를 통해 작업을 처리하는 경우가 있는지를 파악합니다. 그리고 더 간단한 인터페이스를 통해 기능을 제공하는것이 가능한지 확인합니다.
- 새 Facade 클래스에서 간단한 인터페이스를 선언하고 구현합니다. 이 Facade는 클라이언트의 요청을 적절한 컴포넌트(하위 시스템)에 위임하도록 구현해야 합니다.
- 동일하게 하위 시스템으로 작업을 처리하는 부분이 있다면 Facade 를 사용하도록 수정합니다.
1.3. 적용 시기
- 복잡한 하위 시스템으로부터 간단한 인터페이스를 제공하고 싶을때 퍼사드 패턴을 사용합니다. Facade는 서브시스템을 사용할 수 있는 간단하며 기본적인 관점을 제공합니다.
- 클라이언트와 하위 시스템의 구현 클래스와 강하게 결합되어 있을때 퍼사드 패턴을 통해 결합을 약하게 유지할 수 있습니다.
- 하위 시스템에 대한 층(layer)을 두고 싶을때 퍼사드 패턴을 사용하여 하위 시스템을 하나의 레이어로 둘 수 있습니다. 이때 Facade는 하위 시스템 레벨에 대한 진입점의 역할로 정의됩니다.
1.4. 정리
퍼사드 패턴의 경우 개발자들이 별도의 패턴으로 인식하지 않아도 평소에 리팩터링하며 많이 적용해 보았을 만한 패턴입니다. 다양한 컴포넌트를 통해 처리하는 작업이 있고 이 코드가 여러군데서 반복된다면 이를 처리하는 하나의 컴포넌트를 생성하여 중복을 제거하다 보면, 생성한 컴포넌트가 Facade 로 만들어지게 되는것을 많이 경험하였습니다.
퍼사드 패턴을 사용하면 다음과 같은 장점을 얻게됩니다.
첫 번째, 클라이언트가 하위 시스템을 직접 호출하지 않아도 됩니다. 클라이언트는 퍼사드를 통해 하위 시스템의 기능을 사용할 수 있습니다. 두 번째, 클라이언트와 하위 시스템 간의 결합을 약화 시킵니다. Facade 가 중간에서 하나의 레이어로 생성되기에 강하게 결합되어 있었다면 이를 약화시킬 수 있습니다. 마지막으로, Facade 가 존재하더라도 클라이언트는 기존 하위 시스템을 그대로 사용할 수 있습니다.
2. 퍼사드 패턴 구현 시 고려사항
2.1. Reducing client-subsystem coupling - 클라이언트와 하위 시스템 간 커플링 감소
Facade를 추상 클래스로 생성하고 하위 시스템 클래스를 사용하여 구현한다면 클라이언트와 하위 시스템 간 커플링을 감소시킬 수 있습니다. Facade 를 추상 클래스로 생성한다는 말은 다른 구현 Facade 로 교체하여 기능을 확장시킬 수 있습니다.
Facade에 상속을 사용하는것의 대안으로는 Facade 객체에서 사용할 하위 시스템의 객체에 대해 설정할 수 있도록 하는 방법이 있습니다. 사용되는 하위 시스템의 인터페이스 타입을 참조로 갖도록 하여 setter 메서드를 통해 이를 교체할 수 있다면 Facade 에 대하여 subclass를 만들지 않아도 됩니다.
2.2. Public versus private subsystem classes - 논외
Java에서는 Private interface가 지원되지 않습니다.
그렇기에 하위 시스템의 인터페이스에서 public으로 공개된 기능에 대해서만 Facade 가 클라이언트에 제공 가능합니다.