[월:] 2015년 08월

Mediator패턴은 클래스의 구조에 대한 패턴이라기 보다는 프로그램 내에서 이루어지는 작업의 구조에 대한 패턴이라는게 좀 더 명확한 설명이 될 것이다. 대부분의 패턴이 클래스의 배치와 인터페이스에 대한 문제를 중요하게 다룬다면 Mediator패턴은 객체들 사이의 관계와 작업을 유발시키고, 인스턴스들을 제어하는 방법에 초점이 밪추어져 있다는 것을 유념해야 한다.

다루어야 하는 클래스 (또는 인스턴스)가 여러개가 있고, 이것들이 서로 직접적인 상관관계는 없지만, 프로그램 내에서 필요에 따라 느슨한 결합관계를 가지고 어떠한 이벤트에 여러개의 객체가 반응해야 할 때, 이렇게 여러개의 객체를 매번 일일히(개별로)제어한다는 것은 매우 번거로운 작업이 된다. 이런경우 Business Logic에 따라 일련의 규칙을 가지고 있는 클래스를 만들어서, 이렇게 만들어진 클래스로 하여금 규칙에 따라 필요한 다수의 객체를 제어한다면 편하지 않겠는가? 이 개념을 패턴으로 정리하면 Mediator패턴이 된다.

요즘 대부분의 RDBMS 엔진을 보면 Trigger 개념을 지원하고 있다. Database 내의 특정 table 에 대해 특정 transaction을 조건으로 trigger를 걸어서, 해당 table에 이벤트가 발생되었을 때 부수적인 작업이 진행되도록 설정할 수 있다. 이렇게 작업을 미리 준비 해 놓으면 작업자는 추가적인 고민없이 table에 대한 테이터 질의작업을 진행하면, 필요한 추가작업은 자동으로 미리 준비해놓은 규칙에 따라 순서대로 진행 될 것이다. 일종의 Mediator패턴의 개념으로 동작하는 사례라고 볼 수 있지 않을까?

앞엣 설명한대로 Mediator패턴은, 퍼사드의 인터페이스를 정의하거나 규제하기위한 패턴은 아니다. Mediator클래스의 인터페이스는 작업자가 필요한대로 결정하면 된다. 단 Mediator클래스의 관리를 받아야 하는 상황의 종류가 많아진다면 상황별로 Mediator클래스를 여러개 만들어야 할 필요가 있을텐데(물론 하나의 Mediator에 메서드를 늘여서 해결할 수 있다) 이런 경우라면 라이브러리 내에서 공통으로 사용할만한 메서드 인터페이스를 Mediator추상클래스로 정의하고, Mediator하위클래스에서는 상황별로 구체적인 작업을 구현하는것도 좋은 방법이다.

Iterator패턴에 대해서는 여러가지 설명이 있지만 가볍게 보면 Proxy패턴과 비슷해 보이기도 한다. 뒤쪽에 있는 객체를 감추고 접근권한을 통제 한다는 점에서는 충분히 비슷할 수 있다. 하지만 Iterator패턴의 목적을 명확하게 생각해 볼 필요가 있다. 이 패턴은 자로(데이터)의 제어에 그 목적이 있다. 그것도 자료 객체에 자료를 추가하거나 식제하는 등 자료 자체에 무언가 가공을 하는것이 목적이 아니라 자료의 검색에 대한 인터페이스를 제공하고 그 결과를 공급하는것이 패턴의 목적이다. 좀 더 진지하게 고민해본다면, 자료의 제어와 자료의 제공을 분리해서 자료를 다루는 코드를 개념적으로 나누어 코드관리의 효율성과 확장성을 얻을 수 있게 된다.

하나의 자료구조체에 대해 여러개의 Iterator 클래스를 붙인다면, 원하는 알고리즘으로 자료를 다루는 여러가지 방법을 확보하고, 때에 따라 추가할 수 도 있게 된다. 이 패턴은 데이터의 검색에 대한 알고리즘이 어디에 구현되는지에 따라 분류명이 달라지기도 한다. 알고리즘이 데이터클래스에 위치한다면 Iterator 클래스는 데이터의 탐색만 담당하게 되는데 이런경우를 Cursor라고 한다. 여기서 주의깊게 봐야할 부분은 바로 Cursor라고 불리는 이유이다. Cursor 클래스의 인스턴스를 통해 데이터의 탐색을 하는 경우, 이 인스턴스는 Corrent index 값을 가지게 되는데 이런 특성을 이용하면 여러개의 Cursor 인스턴스가 하나의 원본 데이터에 대한 각기 다른 탐색을 진행할 수 있다.

Iterator패턴은 그 특성상 Iterator클래스가 참조하게 되는 데이터 클래스의 자료구조에 대한 특성에 따라 영향을 받게 되는데, 이런 Iterator패턴의 특수성 때문에 Iterator 클래스의 인스턴스는 원본 데이터의 인스턴스와 생성, 제거를 함께 관리하는 “관리용 클래스”에서 취급되는것이 좋으며, 이렇게 관리 클래스를 별도로 작업하는 경우라면 Proxy 패턴으로 구조를 작업해서 데이터 인스턴스를 참조하는 Iterator 인스턴스에 대한 reference counter를 관리해 주는것이 좋다.

interpreter 패턴은 작은 규모의 language에 대한 규칙이 있고, 그 규칙으로 만들어진 구문을 해석하는 해석기를 만드는 경우에 사용되는 패턴이다.

일반적으로 잘 쓰일일은 없는 패턴인데다가 해석의 속도에 대한 효율성을 생각한다면 현실적으로 사용하기에는 권하기 힘든 패턴이기도 하다. 하지만 규칙이 복잡하지 않은 경우 (♣Configuration♣ 파일 형식이나 프로그램의 내장 script 언어 등) 라면 충분히 사용 가능하며, 그 구조상 문법규칙이 확장이 필요한 경우에도 많은 수고를 들이지 않고 필요한 만큼 해석기의 변경도 가능하다.

새로운 문법규칙을 만들려 하는경우, 제대로 된 파서를 처음부터 만든다면 문법규칙이 완성되기도 전에 파서를 수시로 수정해야 하는 상황이 될 것이다. 이 경우 Interpreter 패턴을 사용해서 테스트 단계용 파서를 만든다면, 문법규칙을 일정 수준으로 완성할 때 까지 문법과 파서를 병행해서 관리하는 개발방법을 진행할 수 있다.

Interpreter 패턴에서는 상위클래스인 추상클래스에서 메서드의 인터페이스를 정의하고 하위클래스에서 해석에 사용할 토큰을 각각 별도로 정의하고 해석을 진행한다. 토큰의 요소들은 하위클래스 내부에서 배열 (또는 딕셔너리 또는 Collection) 로 관리되기도 한다.

Interpreter 패턴의 목적은 규칙을 가진 문자열의 해석을 위한 해석기를 구성하는 구조 자체라는것을 잊지 않는다면 패턴의 무분별한 확장을 막는데에 도움이 될 것이다.