목표
이클립스가 어떻게 모델을 UI로서 화면에 표시하는지 그 구조를 간략히 소개한다.
Model
모델은 대게 핵심 임무를 수행하기 위한 비즈니스 코드와, 데이터 구조로 이루어진다. 이는 당신이 가장 관심을 가지고 수행하는 당신만의 일이므로 아무도 간섭을 하지 않는다. 이클립스와 융화되기 위해서 어떠한 인터페이스를 구현하거나 제약을 따라야 할 필요가 없다.[/lang_ko][lang_ko]
Viewer
뷰어는 모델을 화면에 UI로 표현하는 역할을 한다. 하지만 Viewer는 모델과는 아무런 관련도 없고, 심지어 모델이 어떠한 Type의 인스턴스인가에 조차 연연하지 않는다. 모델과 뷰어 사이에는 프로바이더라는 것이 존재하여, 뷰어가 필요로 하는 정보를 모델로부터 얻어내 전달해 주기 때문이다.
Providers
Provider는 대체로 모델로 부터 뷰어들에게 정보를 제공하는 목적으로 만들어진다. 모델이 프로바이더 인터페이스를 스스로 구현하도록 만들어도 되지만, 그 경우 모델이 인프라 스트럭쳐를 구현하느라, 모델 자체의 소스를 어지럽히게 된다. 그렇다고 Provider를 모델의 외부 요소로 만들면, 이 프로바이더는 Model의 구조를 직접 접근할 것이기 때문에, 모델과 프로바이더 사이에 응집성이 발생한다. (다른 모델에서 재 사용할수 없는 전용 프로바이더가 되어 버린다.)
지금까지는 아주 쉬운 이야기 였다. Model - Provider - Viewer는 단순한 구조이다. 여기에 좀더 유연함과 확장성을 부여하기 위해 이클립스는 좀 더 복잡한 트릭을 이용했다.
Base Provider and Adapters
모든 모델마다 소비자에 적합한 Provider를 작성해야 한다면, 얼마나 귀찮은 일이란 말인가. 이를 해결하기 위해 이클립스는 BaseWorkbenchProvider를 제공한다. BaseWorkbenchProvider는 주로 사용되는 뷰어(트리, 테이블 등등)가 필요로 하는 정보를 제공하는 Provider가 구현되어있다. 하지만 어떻게? 모델의 특징과 접근방법을 알지 못하는 상태로 어떻게 동작할 수 있단 말인가? BaseWorkbenchProvider는 먼저 해당 모델의 타입을 이클립스 플랫폼 레지스트리에서 뒤져서, 자기 자신과 연결 가능한 어댑터가 있는지 확인한다. 어댑터가 있다면, 그 어댑터를 이용해서 모델로 부터 필요한 정보를 제공하는 프로바이더를 생성하게 된다. 따라서 당신은 당신의 모델과, 모델이 공동작업을 원하는 대상들에 대한 어댑터를 만들고, 플랫폼에 등록해 주면 된다.
이로서 모델은 완벽한 자유로움을 얻을 수 있게 되는 것이며, 프로바이더는 모델로 부터 정보를 제공함에도 불구하고, 모델에 구애를 받지 않고 만들어질 수 있게 되는 것이다. 이클립스의 가장 대표적인 특징인 루즈 커플링은 바로 이 어댑터 패턴에서 기인한다. 이클립스에서 하나의 객체가 다른 영역에 참가하기 위해서는 인터페이스를 구현하는 방식이 아니라, 별도의 어댑터 클래스를 만들고 이 어댑터를 통해서 관련 상호작용을 처리하게 하는 것이라 할 수 있다.
Model - Adapter - Base Provider - Viewer
다소 복잡해졌지만 그래도 이해할만하지 않은가. 미안하지만 나는 당신을 한번 더 속였다. 모든 것은 이해를 쉽게 만들기 위해서이니 용서하시길. 현행 이클립스 개발자들은 내가 말한 방식으로 이클립스를 사용하지 않는다. 만약 모든 어댑터를 미리 만들어 두어야 한다면 이클립스 JDT처럼 복잡한 어플리케이션의 시작 시간은 엄청나게 느려질 것이다. 이클립스의 또다른 특징중 하나는 Lazy Loading이다. 당장 필요한 상황이 될때까지 어느 것도 미리 준비해두지 않는다. 이를 가능하게 하기 위해 AdapterFactory 패턴이 지금 말한 내용들에 가미되어야 한다. 어댑터를 플랫폼에 등록해 두는 것이 아니라 어댑터 팩토리를 등록해 두어야 한다. 이제 BaseProvider는 필요할 때 어댑터를 생성하고, 프로바이더를 구성할 것이다.
Model - AdapterFactory - Adapter - BaseProvider - Viewer
이것이 이클립스가 어떤 모델이든지 다양한 뷰어로 표현할 수 있도록 해주는 구조이다. 사실 뷰어만 하더라도 StructuredViewer 등과 같이또 세분화 되고, 또 그들이 함께 사용하는 Provider들 역시 세분화 되어있어서, 막상 소스들을 보면 전혀 이해할 수 없을 것이다. 하지만 이 문서는 개념의 소개를 다루고 있으므로 그 범주의 논의는 하지 않겠다.
결론
단순히 모델을 화면에 표시하기 위해서 저정도의 인프라 스트럭쳐를 감내해야 하는것이 못마땅할 수도 있다. 하지만 당신이 만들어야 하는 것은 오직 모델과 어댑터 팩토리 뿐이다. 저 약속만 지키면 당신의 모델은 모든 이클립스 컴포넌트와 친구가 된다.
- 이클립스의 구성요소는 같은 목적을 가진 영역에 참가하기 위하여 서로를 위한 매개 객체인 Adapter를 이용한다. 이는각 컴포넌트의 독립성을 보장한다.
- 이클립스는 Lazy Loading을 위해 개발자들이 Factory Pattern을 사용하는 것을 장려한다.
- 뷰어는 프로바이더를 이용하여 모델의 내용을 표시한다.
- 이클립스 플랫폼은 모델에 등록되어있는 팩토리 어뎁터가 있는지 확인하고 이를 이용해 어댑터를 만들고, 이 어댑터와 베이스 프로바이더를 결합하여, 화면에 보여줄 정보를 생성, 뷰어가 이를 표시한다.
Tags: Eclipse