'2011/11'에 해당되는 글 1건

  1. 2011.11.06 Façade Pattern 을 사용하면 좋은 이유. (1)
Design Pattern2011.11.06 15:15
패턴이라는 말이 GoF 디자인 패턴 덕에 어려운말이 되어 버린것 같습니다.

여러분들을 샤워 하고 주무시나요? 아침에 일어나서 샤워 하시나요?
이런 반복적이고 자신에게 맞는 반복적인 행위를 어렵게 말 하면 디자인 패턴이라고들 하더군요...

팩토리, 싱글톤, 옵저버 등의 패턴이 실제로는 우리가 일상생활에서 반복적으로 하고 있는 어떠한 행위들에 대한것이죠.
맞다 틀리다는 없습니다. 하지만 적어도, 편하다 라고는 될수 있죠.

그럼 어떠한 시스템을 개발을 할때 제가 경험해본 편한 패턴에 대해 소개 하겠습니다.

프로젝트의 덩치가 커지면서 각각의 서브시스템들은 복잡도가 높아지기 마련입니다. 이러한 복잡도 높은 서브시스템을 관리하기란 쉽지가 않죠. 그러다가 고안해 낸 방식이 CBD입니다. 재사용성을 높이고, 유지보수를 좋게 하기 위한 방법이죠.

각각의 서브 시스템을 컴퍼넌트로 쪼개어서 사용하는 방식입니다.

물론 이때 부터 어떻게 보면 묵시적인 퍼샤드 방식인 셈이죠.(아닌가요? ^^; 저는 그렇게 생각 하고 있습니다.)

퍼샤드 패턴을 사용하지 않은 경우의 의존성에 대한 간단한 그림을 보도록 하겠습니다.

어떠한 기능을 하는 클래스를 사용하기 위해 직접 호출을 합니다. 예를 들어 닷넷 에서는 네임스페이스라 일컽는 녀석을 추가해 주고, 해당 클래스들을 곧바로 인스턴스화 하여 사용하곤 합니다.

그러한 Client Class 와 각각 서브시스템에 있는 하위 클래스들(위 그림에서 빨간 상자)이 수정이 필요할때 수정을 하기가 간단하지는 않을것 입니다. 이것을 서브시스템 단위(컨퍼넌트)로 관리해 주는 무언가(Façade Object)가 있으면 좋다고 생각이 됩니다. 그러면 그림은 다음처럼 바뀌어 지게 됩니다.


이런... 비스타에 있는 캡춰 툴을 사용했더니 테두리가 빨간색으로 처리되네요.. ㅡㅡ;

위처럼 퍼샤드 객체를 서브시스템(패키지)의 인터페이스 라고 생각해 봅시다.

어떤가요? 이러면 Dependency 가 낮아지겠죠? 이렇게 해서 뭐가 낮아질까 라고 생각 할수도 있겠지만, 통상 객체간의 결합도를 낮추기 위해서는 인터페이스를 이용한다고 하죠. 그와 같은 이치입니다.


제가 생각하는 퍼샤드 객체는 안내데스크 입니다. 예를 들어 실생활에서 어떠한 건물에 입주해 있는 회사가 아래 그림과 같다고 한다면, 고객은 MS를 가기위해 2층으로 올라가게 됩니다.



그러다 MS 사업 확장을 하면서 4, 5 층으로 사무실 이전을 할 경우 그것을 모르는 고객이 2층으로 갔다면 낭패 입니다.
이러한 혼동을 막고자 안내데스크를 두게 되면 고객 입장에서는 더할나위 없이 좋을것입니다.
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by dotnetpower

티스토리 툴바