[객체지향설계 & 패턴] 퍼사드 패턴

개요

 어댑터 패턴에 이어 인터페이스와 관련된 패턴 중 하나인 퍼사드(Facade) 패턴에 대해 알아보겠다. 이 패턴은 어느 경우에 사용하는 게 좋을까?

 프로그램 개발 과정에서 규모가 너무 커져 클래스도 너무 많고 많은 클래스 사이 의존성이 생겨 특정 클래스의 메소드를 먼저 호출해야 하는 등 클래스의 제어가 어려워질 수 있다. 많은 클래스를 프로그래머가 따로따로 관리하다 보면 실수가 발생할 수 있을 것이다.

 이때, 많은 클래스를 한번에 모아서 한 곳에 깔끔하게 정리를 한다면 어떨까?? 많은 클래스를 모아 관리 창구를 만드는 것, 이것이 Facade 패턴의 주요 목적이다.

예시

 집을 예시로 생각해보자. 힘들게 과제와 프로젝트를 끝나고 밤늦게 집으로 향한 컴퓨터공학과 학생은 집에 도착하여 무슨 행동을 가장 먼저할까? 반드시 먼저 현관(porch)에서 신발을 벗고, 거실(livingRoom)의 불을 켜야 할 것이다. 그리고 화장실(bathroom)에서 세면을 하고, 방(room)에 들어가 휴식을 취할것이다. 이 불쌍한 컴퓨터공학과 학생이 귀가하여 이 행동들을 반드시 순서대로 수행한다고 생각하자. 

 이제 방들을 각각의 클래스라고 생각하고, 각 방에서 하는 행동을 메소드(함수)로 생각해보자. 4개의 클래스 porch, livingRoom, bathroom, room이 있고 반드시 porch 클래스에서 신발을 벗는 takeOffShoes 메소드를 먼저 실행해야 한다. 이후 livingRoom 클래스에서 불을 키는 turnOnTheLight 메소드를 실행하고, bathroom 클래스에서 세면을 하는 wash 메소드를 실행한다. 마지막으로 room 클래스에서 휴식하는 rest 메소드를 실행하는 것으로 이 학생의 루틴을 정의할 수 있다.

 이것을 프로그램으로 만들 때, routine 클래스에 porch, livingRoom, bathroom, room를 모두 넣어 학생이 방에서 하는 행동을 순서대로 클래스에서 메소드를 호출하여 구현한다면 4개의 클래스를 왔다갔다 할 필요 없이 routine 클래스 하나로 학생의 행동을 모두 정의할 수 있다. 이때, routine 클래스가 개요에서 말한 창구 Facade가 된다.

 이 예시에서 클래스도 4개밖에 안쓰고 각 클래스에는 메소드가 하나밖에 없는데 뭐하러 Facade 패턴을 적용하느냐 할 수 있다. 하지만 여기서 클래스가 여러 개 추가되고, 각 클래스에 메소드가 6~7개씩 추가된다면 분명히 클래스의 제어는 어려울 것이므로 Facade 패턴을 적용해 API 수를 줄일 수 있다.

구성 요소

Facade

 창구 역할을 맡는 클래스로, 높은 수준의 단순한 인터페이스(API)를 시스템 외부에 제공한다. 위 예시에서는 routine 클래스가 학생의 귀가 후 행동을 간단하게 정의하고 있으므로 Facade가 된다. 

Client

 Facade 패턴을 이용하는 요소로, 클라이언트는 Facade 패턴 안에 포함되지 않는다. 위 예시를 프로그램으로 작성해 Main 클래스에서 routine 클래스를 사용한다면 Main 클래스가 클라이언트가 될 것이다.

마무리

 확실히 어댑터 패턴보다는 이해가 더 쉬웠다. 큰 리빙 박스 안에 장난감들을 정리하는 것으로 생각하면 이해하기 쉬울지도..? 이렇게 되면 큰 리빙 박스가 창구 역할의 Facade가 될 것이다.