파사드(Facade) 패턴

프로그램이라는 것은 점점 커지는 영향이 있다.

많은 클래스가 만들어져 서로 관계를 맺으면서 복잡하게 된다.

클래스를 사용할 경우에는 클래스 간의 관계를 정확히 이해하고 정확한 순서대로 메서드를 호출할 필요가 있다.

커다란 프로그램을 사용해서 처리를 실행하려면 상호 관련된 많은 클래스를 적절하게 제어해야 한다.

그렇다면 그 처리를 실행하기 위한 ‘창구'를 준비해 두는 것이 좋다.

그렇게 하면 많은 클래스를 개별적으로 제어하지 않아도 그 ‘창구'에 대해서만 요구하면 역할이 끝나기 때문이다.

이러한 ‘창구’가 바로 파사드 패턴이다.

파사드는 ‘건물의 정면'이라는 의미를 가지는데, 파사드 패턴은 복잡하게 얽혀 있는 것을 정리해서 높은 레벨의 인터페이스(API)를 제공한다.

파사드 역할은 시스템의 외부에 대해서는 단순한 인터페이스(API)를 보여준다.

시스템의 내부에 있는 각 클래스의 역할이나 의존관계를 생각해서 정확한 순서로 클래스를 이용한다.

다음 링크는 파사드 패턴의 예제 코드다.

GitHub - kkoon9/Java-Design-Pattern: Java 언어로 배우는 디자인 패턴 입문 예제 코드

예제 프로그램은 maildata.txt을 읽어서 해당 텍스트 파일에 있는 정보를 웹 페이지에 뿌려준다.

파사드 패턴의 등장인물

Facade(정면)의 역할 - PageMaker

시스템을 구성하고 있는 그 밖의 많은 역할에 대해 ‘단순한 창구'가 된다.

Facade 역할은 높은 레벨에서 단순한 인터페이스(API)를 시스템 외부에 제공한다.

그 외 역할 - Database, HtmlWriter

시스템을 구성하는 다른 많은 역할은 각각의 임무를 실행하지만 Facade 역할에 대해서는 신경쓰지 않는다.

Facade 역할에서 호출되는 임무를 실행하지만, 다른 역할이 Facade 역할을 호출하는 일은 없다.

Client(요구자)의 역할 - Main

Facade 패턴을 이용하는 역할이다.

Facade 역할은 무엇인가?

Facade는 복잡한 것을 단순하게 보여준다.

🤔
그 ‘복잡한 것’이 무엇일까?

 

내부에서 실행되고 있는 많은 클래스의 관계나 사용법이 ‘복잡한 것'을 말한다.

Facade 역할은 그 복잡한 것을 의식하지 않도록 해준다.

여기에서의 핵심은 인터페이스(API)를 적게 하는 일이다.

클래스나 메서드가 많이 보이면, 프로그래머는 무엇을 사용하면 좋을지 망설이게 되고, 호출하는 순서에도 주의해야만 한다.

주의해야 한다는 것은 틀리기 쉽다는 것이다.

따라서 인터페이스(API)가 적은 Facade 역할을 생각하는 것이 좋다.

인터페이스(API)의 수가 적다는 것은 외부와의 결합이 소원하다고 표현할 수 있다.

외부와의 소원한 결합, 약한 결합, 유연한 결합은 패키지(클래스의 집합)을 부품으로써 재이용하기 쉽게 해준다.

클래스를 설계할 때에는 어떤 메서드를 public으로 할지 생각한다.

너무 많은 메서드를 public으로 하면 클래스 내부를 수정하기 힘들게 된다.

필드에 대해서도 마찬가지다.

뜻하지 않게 필드를 public으로 하면 다른 클래스가 그 필드의 내용을 멋대로 참조하거나 변경하기 때문에 클래스의 수정이 힘들게 된다.

이 내용은 ‘이펙티브 자바’ 아이템 15 포스팅을 참고하자.

아이템[15]. 클래스와 멤버의 접근 권한을 최소화하라

재귀적인 Facade 패턴의 적용

Facade 역할을 가진 클래스의 집합이 여러 개 있다고 가정하자.

이때 클래스의 집합을 정리해서 새로운 Facade 역할을 도입할 수 있다.

즉, Facade 패턴을 재귀적으로 적용하는 것이다.

상당히 큰 시스템이 다수의 클래스, 다수의 패키지를 포함하고 있을 때 요소요소에 Facade 패턴을 적용하면 시스템은 보다 편리하게 된다.

관련 패턴

• Abstract Factory 패턴
• Singleton 패턴
• Mediator 패턴