구조 패턴 - 퍼사드(Facade)

- 참조: GoF의 디자인 패턴

- 참조: https://refactoring.guru/design-patterns/facade

- God object: https://en.wikipedia.org/wiki/God_object

- 퍼사드(Facade) 패턴

퍼사드(Facade) 는 용어 부터 낯설게 느껴지는것 같아 사전적 정의부터 살펴보는게 좋겠다. Facade는 정면, 표면이라는 뜻으로 이를 알면 왜 패턴의 이름이 퍼사드인지 알 수 있다. 퍼사드 패턴은 라이브러리나 프레임워크 혹은 클래스들의 집합과 같은 서브시스템을 사용하기 쉽도록 하나의 간편한 인터페이스를 제공하는 패턴이다.

---

- 시나리오

비디오 파일을 사용자가 요청한 format 으로 변경해주는 응용프로그램이 있다고 가정하자. 비디오 파일 포맷 변환에 참여하는 클래스에는 VideoFile, AudioMixer, MPEG4Codec 등 많은 클래스가 있다.

 

단순하게 구현하면 상세한 클래스들을 직접 사용해서 기능을 구현하면 된다. 하지만 이렇게 프로그램을 작성하면 응용프로그램의 비즈니스 로직이 해당 클래스들과 강하게 결합되며, 의존성관리등 많은 문제가 생길 수 있다.

---

- 실생활 비유를 통한 이해

GoF의 디자인 패턴에서는 위의 시나리오 예제로 설명하지만 이해하기 힘들수도 있다. 참조링크 https://refactoring.guru/design-patterns/facade 에서는 퍼사드 패턴을 실생활의 예제와 엮어서 쉽게 설명하고 있다.

 

우리가 쇼핑몰에 전화 주문을 하면 상담원을 통해 주문을 처리할 수 있다. 이때 상담원이 해당 쇼핑몰의 모든 서비스들과 부서들의 퍼사드(Facade)라고 할 수 있다. 상담원은 우리에게 주문, 결제, 배송 서비스에 대해 Voice 인터페이스를 제공한다고 할 수 있다.

---

- 문제 해결과 패턴의 적용

위 다이어그램은 Video Subsystem에 대해 퍼사드를 제공한다. 참여자들을 통해 다이어그램을 분석해보자.

• Client(Application): 어떤 기능을 동작시키기 위해 서브시스템의 클래스들을 이용해야하는 사용자이다.
• Facade(VideoConverter): Video Subsystem에 대해 단순하고 획일화된 인터페이스를 제공한다. 해당 인터페이스의 기능을 구현하기 위해 서브시스템의 클래스들이 어떤 동작을 처리하는지 잘 알고 있다.
• Subsystem(MPEG4 Codec, VideoFile...): Facade 에 대한 참조자를 갖고 있지 않으면서, 실제 동작을 수행하는 클래스들이다.

---

- 장점과 단점

퍼사드는 위에서 언급한대로 서브시스템과 사용자간의 결합도를 낮추고, 복잡도를 줄여준다. 딱히 단점은 없을 것 같지만 Facade 안에서 서브 클래스들이 모두 참조되고 있으므로, 그 자체가 하나의 God object(https://en.wikipedia.org/wiki/God_object)가 될 수 있다.

---

- 다른 패턴과의 관계

퍼사드는 어댑터 패턴과 차이점이 있는가 싶을 정도로 상당히 비슷해보인다. 퍼사드는 서브클래스들에 대해서 새로운 인터페이스를 정의하지만, 어댑터는 존재하는 인터페이스를 이용한다. 또한 어댑터는 1 개의 객체를 wrapping 하지만, 퍼사드는 서브시스템의 객체들과 협력한다.

그 외에도 다른 패턴들과의 관계 설명은 (https://refactoring.guru/design-patterns/facade)를 참조 바란다.

---

- 마치면서

여태까지 살펴보았던 예제들은 Java 코드로 구현했지만, 퍼사드는 난이도가 있거나 구현방법에 중점이 있지는 않다는게 개인적인 생각이다. 이 패턴을 도입하는게 좋은지, 퍼사드를 도입한다면 인터페이스의 기능은 어떻게 정의해야 사용자에게 획일화되고 간단한 인터페이스를 제공할 수 있는지가 더 관건인것 같다.