[월:] 2015년 08월

Command 패턴은 어떠한 작동을 시작과 분배, 작업부로 나눔으로서 각 부분에 대한 유지보수와 느슨한 연결을 통한 재사용성을 높이는데 그 목적이 있다. 실행되어야 하는 실제 작동내용을 구현하고 있는 클래스와 작동을 시작시키는 부분을 분리함으로서 작업부는 필요한 만큼 재사용 될 수 있으며 작업부는 또한 실제 구현부를 따로 둠으로서 코드관리에 유연성을 확보한다

Command패턴에서 최상위 클래스는 명령부에 대한 인터페이스만 확보하는 추상클래스로서 하위클래스의 동작 스타일을 정의하게 된다. 일반적인 Application의 예를 들어보자. 사용자는 종종 프로그램의 mainmenu와 popup에서 동일한 menuitem을 확인할 수 있다. 물론 양쪽의 menuitem은 대부분의 경우 동일한 동작을 할 것이다. 이 때 menuitme의 코드에서는 동일한 명령클래스를 (또는 인스턴스를) 호출하는 코드를 가지고 있을 것이다. 이런식으로 실제 동작과 동작을 필요로하는 부분이 분리되어 있다면 그건 Command패턴으로 봐도 무방하다고 생각한다.

Command패턴은 그리 복잡하지 않다. mobile app을 예로 들어보자. mobile app에서는 각종 제스처가 사용된다. 하지만 어떤 체스처라고 해도 반드시 어떤 작동을 일으키기 위한 목적을 가지고 있다. 그렇다면 제스처의 검출 부분과, 제스처의 검출 시 어떤 동작을 할지를 별도의 구조로 분리해서 동작부분만 따로 클래스군으로 관리한다면 새로운 동작을 테스트하기 쉬운 제스처로 연결만 했다가 테스트가 끝난 다음 원하는 제스처로 연결을 바꿔주면 개발 및 코드의 유지보수도 쉽게 할 수 있다.

이렇게 필요한 부분을 분리하고, 역할을 할당하는 구조를 논의하고 규정하는게 Design pattern 이지만 Command패턴은 그 중에서도 단순하며 명확한 패턴이다.

Chain of Responsiblity는 그대로 직역하자면 “책임 연쇄”가 된다. 하지만 이는 너무 직관적인 번역이라고 생각한다. 좀 더 고민해 보자면 “책임을 가지고 있는 연쇄” 정도가 될거고, 더 풀어보자면 “연쇄적 책임”이 되지 않을까 한다.

이 패턴은 조금은 특이하며 조금은 재귀적인 느낌을 준다. Client로 부터 요청을 받은 객체는 자신이 요청에 응답할 준비가 되어있지 않을 때 자신의 상위클래스로 수신한 요청을 전달한다. 이렇게 요청을 전달받은 상위 클래스는 요청에 대한 응답을 할 준비가 상위클래스 자신에게 되어있는지를 살펴보고 자신에게 준비가 되어있지 않다면 스스로에 대한 상위클래스로 요청을 다시 전달한다. 이렇게 요청을 계속 위로 전달해서 client의 요청에 적합한 준비가 된 클래스가 요청에 대한 행동을 진행한다. 이 방식의 단계에 대한 구조가 바로 Chain of Responsiblity 패턴이다.

Chain of Responsiblity 패턴이 성립하기 위해서는 가장 중요한 요건이 두가지가 있다. 하나는 요청을 받은 클래스의 전체 구조에서 요청에 대한 클래스(인스턴스)의 메서드는 동일한 인터페이스를 가지고 있어야 하며, 해당 요청을 처리하는 메서드 내부에서 ♣위줄♣의 객체로 요청을 전가하는 기본동작은 필요단계의 제일 위쪽에 있는 클래스에 선언되고, 그대로 아래쪽으로 상속되어야 한다는 점이다.

상위클래스에서 상속된 하위 클래스는 Client의 요청을 분석하고, 자신이 처리해야 할 필요가 있는 경우라면 메서드를 오버라이드 하면 된다. 그러면 요청의 내용에 따라 자신이 해야하는 처리가 있는 경우에 대한 동작만 새로 정의하면 된다. 이런 방식의 구현을 통해서 계층구조에서 작성되어야 하는 코드의 분량을 효율적으로 줄이고 관리의 용이성을 확보할 수 있다.

Proxy패턴의 핵심은 “허상같은 객체”라는 점이다. Proxy객체는 Client에 대해서는 실제적 클래스 같은 역할을 하지만 그 정체는 “대리자”에 가깝다. Proxy 객체는 실제적인 역할을 하는 인스턴스가 존재(생성전) 하지 않더라도 Client의 요청에 대해 아무일도 없는것처럼 중간처리를 모두 맡아서 한다.

[디자인 패턴]에서도 Proxy 패턴의 몇가지 유형이 나오지만 이중에 백미는 분산 객체라 할 수 있다. Client는 마치 Local에 존재하고 있는 객체인 것 처럼 사용하지만 Proxy객체 내부에서는 원격지에 있는 객체라고 하더라도 문제없이 처리하며 network 문제등의 상황에서 복잡한 경우들을 책임진다. 현재의 분산객체 시스템의 원형이라 할 수 있으며 Client는 별도의 network 상황을 고려하지 않고 Local 객체를 처리하듯, 일관성있는 개념으로 프로그래밍을 할 수 있다. 프로그램의 작성에 있어서 이런 통일된 개념은 중요하다.

그리고 Proxy패턴의 도 하나 장점은 리소스의 절약에 있다. 실제 시스템에서 많은 리소스를 사용하는 인스턴스를 필요할 때 만 사용하려 하는 경우 해당 인스턴스의 생성 및 관리(창조자 (reference) 카운팅 등)를 Proxy객체에서 담당하고 Proxy객체는 관리하는 실제 인스턴스와 동일한 인터페이스를 사용함으로서 Client에게는 코드의 일관성을, 시스템에 대해서는 효율적인 리소스의 사용을 가능하게 해준다.