움직이는 타켓을 멈추게 하라

너무 당연하지만, 움직이는 타겟을 맞추는 것보다, 멈춰 서 있는 타켓을 맞추는 일이 휠씬 쉽습니다.  그와 같이, 객체를 상대하다보면 메시지를 전달해야 할 객체가 불특정 다수이거나 고정된 것이 아닐 경우는 최대한 피해야 합니다.  

참조 할 객체 자체가 상황에 따라 변하게 되면, 논리적으로 복잡해 질 뿐 아니라, 예상하지 못한 결과를 가져 올 가능성이 높기 때문입니다.  이러한 코드는 디버깅마저도 어렵게 합니다.

[그림 1]은 제가 만든 온라인 강의 시스템의 실행 화면 일부입니다.  (http://www.himytv.com/)

[그림 1] 실시간 온라인 강의 시스템

왼쪽 사진이 있는 곳이 강의 내용을 담아서 수강생들에게 전송되는 영역입니다.  강의 내용을 담는 모듈들은 화이트보드, 동영상 화면 등 여러 종류의 교재를 사용하게 됩니다. 

일단 무식하게 접근해보도록 하겠습니다.  교재를 담을 영역을 Conainer 객체라고 하고, WhiteBoard 객체를 그 위에 올려 놓아야 한다고 가정하겠습니다.  ([그림 1]에서 화이트보드 버턴을 클릭한 시나리오)

실제 프로그램은 델파이로 작성되어 있지만, 자바를 의사코드로 사용하고 있습니다.

[소스 1]

void on_Click() {
  WhiteBoard.Parent = Container;
}

이제 다른 교재창이 프로그램 내부가 아니라, PC 화면 전체를 사용해야 하는 경우를 생각해 보겠습니다.  [소스 2]는 그러한 경우를 표현한 코드 입니다.

[소스 2]

void on_Click() {
  if (isFullScreen) {
    WhiteBoard.Parent = nil;
    WhiteBoard.setRect( Screen.getLeft(), Screen.getTop(), Screen.getWidth(), Screen.getHeight() );
  } else {
    WhiteBoard.Parent = Container;
  }
}

결국 [소스 2]는 "화이트보드를 화면에 표시해라" 라는 메시시를 처리하기 위해서, 상황에 따라서 다른 객체를 참조하는 형식을 취하고 있습니다.  책임이 한 곳에 집중되어 있지 않기 때문에 다른 변화에 의해서 취약한 부분이 되는 것도 문제이지만, 앞서 언급한 것과 같이 디버깅이 어려워 집니다.

[소스 3]

void on_Click() {
    Container.Show( WhiteBoard );
  }
}

Container.Show() 메소드 내부에는 결국 [소스 2]의 내용이 들어가야 합니다만, 버턴을 클릭하고 화이트보드의 위치를 조정하는데 내부 사정을 일일히 알 필요 없이, Container 객체에게 완전하게 위임을 하게 되어 보다 이해하기 쉬운 코드가 되었습니다.  이제 화이트보드를 화면에 표시하는 내부 조건이 어떻게 변화하더라도, 버턴을 처리하는 UI 부분에서는 그러한 영향을 받지 않게 되었습니다.  훌륭하게 분업화가 이루어 진 것 입니다.