디자인 패턴
- 자주 사용하는 설계 형태를 정형화하여 이를 유형별로 설계 템플릿을 만든 것이다.
- 코드 구현 과정에서 자주 발생하는 문제들을 해결하기에 편리하다.
디자인 패턴 분류
GoF는 23개의 디자인 패턴을 3개로 분류하였다.
1) 생성 패턴
- 클래스 정의, 객체 생성 방식을 구조화하고 캡슐화하는 방법을 제시한다.
- 인스턴스를 효율적으로 생성하여 코드 유연성과 재사용을 증가하도록 한다.
2) 구조 패턴
- 클래스나 객체를 조합하여 더 큰 구조를 만드는 방법을 제시한다.
- 복잡한 구조를 갖는 시스템을 개발하기 쉽도록 만든다.
3) 행위 패턴
- 클래스나 객체가 상호작용하는 방법과 책임을 분산하는 방법을 제시한다.
Facade Pattern
Facade: (건물의) 정면, 앞면, 표면
-
복잡한 서브 시스템을 한 인터페이스로 묶어 단순화하는 패턴이다. 즉, 전면 인터페이스 역할을 하는 객체이다.
-
클라이언트는 통합된 인터페이스(=Facade 객체)만을 사용하여 더 쉽고 간편하게 서브 시스템을 사용할 수 있다.
-
클라이언트와 서브 시스템을 분리함으로써 클라이언트의 부담을 줄여줄 수 있다.
Facade를 사용하지 않을 경우
Facade를 사용하지 않을 경우, 클라이언트는 클래스 A~D 모두에 접근하게 된다.
클래스가 많아질수록 클라이언트의 클래스 의존성은 높아지며, 코드 리팩토링이 어려워진다.
Facade를 사용할 경우
Facade를 사용할 경우, 클래스 A~D를 subsystem화 하여 한 인터페이스로 묶을 수 있다. 클라이언트는 Facade 객체와만 상호작용을 하여 클래스 간 의존 관계가 줄어든다.
예제
Smart Tv를 작동하는 것을 예시로 들어본다.
Smart Tv를 작동 시작하기 위해서는 화면과 소리가 켜져야 하고, 인터넷이 연결되어야 한다.
우리는 현실에서 화면, 소리, 인터넷을 따로 작동하지 않고 리모컨을 사용하여 Smart Tv를 작동한다.
이처럼 퍼사드 패턴은 Smart Tv의 리모컨을 만든다고 생각하면 된다.
코드 예제를 살펴보자.
전원 On, Off 메서드를 가지고 있는 Power 인터페이스를 만든다.
Screen, Sound, Internet 클래스는 Power 인터페이스를 구현하여 각 클래스에 맞게 오버라이딩 한다.
클라이언트가 리모컨 없이 SmartTv를 작동한다면, Screen, Sound, Internet 객체를 각각 생성하고 매번 각 객체의 on, off 메서드를 실행해줘야 한다.
클라이언트는 번거럽고 복잡한 과정을 매번 거쳐야 하는 것이다.
클라이언트에게 편리성을 제공하기 위해 리모컨 퍼사드 클래스를 생성한다.
리모컨의 on, off 메서드를 통해서 Screen, Sound, Internet 을 한 번에 켜고 끌 수 있게 되었다.
이제 클라이언트는 리모컨을 사용해서 SmartTv를 작동할 수 있게 된다.
이처럼 퍼사드 패턴은 클라이언트에게 통합된 인터페이스를 제공함으로써 간편하게 서브 시스템을 사용할 수 있게 한다.
활용 - MVC 패턴
MVC 패턴을 적용하여 <게시판 서비스> 중 게시글 조회 기능을 만들었다고 가정하자.
현재 Board Controller는 게시판 글을 조회하기 위해 Board Service, Comment Service, Image Service를 모두 호출하고 있다.
이 경우, Controller가 각 서비스 로직과 강하게 결합되어 있는 것을 뜻하며, 기능이 많아질수록 순환참조, 코드 중복 등의 이유로 유지보수가 어려워질 것이다.
이를 해결하기 위해 BoardFacade 클래스를 정의한다.
BoardFacade는 Controller 대신 각 서비스를 호출하여 비즈니스 로직을 처리하도록 한다.
이제 Controller는 BoardFacade 객체를 통해서 게시글 조회 기능을 호출할 수 있다.
Controller와 Service 단의 연결을 느슨하게 만들 수 있으며, Controller를 깔끔하게 유지할 수 있게 된다.
참고
