구조 관련 : 파사드 패턴

들어가기 전

이 글은 백기선님의 GOF 디자인패턴 강의를 복습하며 작성한 글입니다. 

---

파사드 패턴

• GOF :  복잡한 서브 시스템 의존성을 최소화 하는 방법 
• 파사드는 건물의 전면을 의미함. 
  • 우리는 전면만 보니 내부가 어떻게 되어있는지 알 수 없음. 예를 들면 전기, 파이프 배관을 모름.
  • 소프트웨어 관점에서 말하면 파사드를 이용해 모든 디테일한 부분을 숨기는 것임.  즉, 서브 시스템의 의존성을 Facade 안쪽으로 숨길 수 있음.
• 파사드 패턴을 이용해 서브 시스템 의존성을 파사드로만 집중 시킬 수 있음.
  • 서브 시스템의 동일한 기능을 사용하는 클라이언트가 많은 경우 도움이 될 수 있음.
  • 서브 시스템의 기능을 사용하기 위한 절차에 대해 클라이언트가 몰라도 됨. (메일을 보내려면 세션부터 만들어야 한다던지)

 

---

예제

• 메일 보내는 코드를 보자. 
• 의존성이 굉장히 많음.
• 클라이언트가 프로퍼티, Session, MimeMessage, Transport, Exception까지 특정한 라이브러리에 대한 다양한 의존성이 생김. 
• 스프링 자체도 스스로를 노출시키는 것을 좋아하지 않음. 즉, 스프링 소스 코드를 직접 사용하기 보다는 개발자들 자신의 코드만 집중하기를 원함. (Loosely Couped 되는 것을 원함)
• 단단히 결합될 수록 변경하기도 어렵고, 테스트하기도 어려움. 따라서 느슨하게 결합하는 것을 원함. 
• 그런데 이 맥락에서 보면 이 코드는 굉장히 타이트하게 결합되어 있음. (자바의 이메일 라이브러리에 의존함) 
  • 이 부분을 파사드를 이용해 개선할 것임. 

 

 

파사드 패턴

• 복잡한 서브 시스템 의존성을 최소화 하는 방법
• 클라이언트가 사용해야 하는 복잡한 서브 시스템 의존성을 간단한 인터페이스로 추상화 할 수 있음. 
  • 사용하는 기능 하나에 대한 인터페이스, 오퍼레이션 하나로 딱 압축시켜서 클라이언트는 파사드의 특정 메서드만 이용하도록 하고, 디테일을 파사드의 뒤로 모두 숨긴다. 
• 조삼모사 패턴일까?
  • 클라이언트가 직접 특정 라이브러리에 의존하는 것을 방지하기 위해 파사드를 만들고, 파사드 뒤로 라이브러리 의존을 넘긴다. 이 말은 결국에는 뒷쪽에서 특정 라이브러리를 참조하기 때문에 의미없는 것이 아닐까?
  • 그렇지 않음. 만약 이 기능을 사용하는 클라이언트가 많다면, 클라이언트가 사용하는 코드를 공통으로 빼놓을 수 있음. 따라서 특정 라이브러리에 의해 변경이 필요할 때, 수정해야 하는 부분이 파사드만으로 집중됨. (이런 관점에서 의미가 있을 수 있음) 

 

 

예시

• 이전 코드는 단단히 자바 이메일 라이브러리에 결합되어 있음. 여기서 파사드 패턴을 이용해 느슨한 결합을 달성할 것임.
• 추상화는 정답이 있는 것이 아님. 여기는 다음과 같이 나누려고 함. 
  • 메일을 보내는 역할을 하는 클래스. (EmailSender) → EmailSettings를 멤버로 가지게 함. 그리고 여기서 sendEmail()할 때 EmailMessage를 받도록 할 듯. 
  • 메일의 설정 (EmailSettings) : Host 정보
  • 메일의 메세지  (EmailMessage) : To, From은 이곳에.
• Client는 EmailSender(), EmailSettings, EmailMessage를 이용할 수 있음. 이렇게 하면 자바 라이브러리에 대한 의존성은 사라짐. 다만 우리가 만든 파사드에 의존해야만 함. 
  • 이전에 사용하던 코드에 비해 MockUp 하기 쉬워짐. 이전 코드에서는 Properties가 있어야 Session이 되고, Session이 있어야 MimeMessage가 되고... 이런 식으로 얽혀있었음. 

 

 

 

장 / 단점

• 장점 : 서브 시스템에 대한 의존성을 한 곳으로 몰아주는 점임. 나중에 서브 시스템 변경이 필요할 때, 파사드 부분만 변경하면 됨.
• 단점 : 파사드가 서브 시스템에 대한 모든 의존성을 가짐. 

단점을 보면 조삼모사라고 생각할 수 있다. 그러나 파사드를 사용하는 클라이언트가 이곳 저곳에 있다면 변경지점을 파사드 하나로 몰아둘 수 있다. 또한 서브 시스템에 대한 이해를 파사드로 몰아두었기 때문에 클라이언트는 단순히 사용하기만 할 수 있다. 이 관점에서도 꽤 좋은 역할을 할 수 있게 된다.