매커니즘과 정책을 분리하라

2008.08.31:
"Art of Unix Programming"을 보면 Unix의 철학을 언급하면서
"매커니즘과 정책을 분리하라(인터페이스와 엔진을 분리하라)" 는 말이 나온다.

이 원칙을 가장 잘 설명해 줄 수 있는 예가 "X Windows system"인데,
X프로토콜을 이용한 서버 클라이언트 방식으로 X서버는 일반 그래픽 연산이나
입출력 만을 수행하고, 어플리케이션은 Xlib을 포장한 GTK나 QT 등의 X툴킷에 따라
달라질 수 있다.

매커니즘과 정책을 분리하는 큰 이유는 매커니즘은 오래 지속되지만 정책은 훨씬 빨리
변하기 때문이다. (그래픽 연산의 동작은 오래 지속되지만 툴킷의 유행은 빠르게 변한다.)

이 원칙을 적용한 최소한의 예를 보자.
다음 코드는 어떤 프로젝트에서 시스템 에러상황을 파악하기 위해
로그를 남기기로 한 경우이다.

/**
@brief: mechanism와 policy의 분리예제. 이거때매 손코딩하게 될지 몰랐다..
 */
void foo()
{
  ...
  if (시스템 에러)
    fprintf(stderr, "System Error! - errorNo(%d)\n", errorNo);
}

void bar()
{
  ...
  if (시스템 에러)
    fprintf(stderr, "System Error! - errorNo(%d)\n", errorNo);
}

위 경우는 매커니즘과 정책이 분리되지 않은 최소한의 예이다.
분리시킨다면..

/**
@brief: mechanism와 policy의 분리
 */
void foo()
{
  ...
  if (시스템 에러)
    SystemErrorPolicy(errorNo);
}

void bar()
{
  ...
  if (시스템 에러)
    SystemErrorPolicy(errorNo);
}

void SystemErrorPolicy(int errorNo)
{
  fprintf(stderr, "System Error! - errorNo(%d)\n", errorNo);
}

이 두 경우는 어떤 차이가 있나?
만약 정책이 바뀌어 시스템 에러 상황에서 프로그램을 종료 시키기로 결정했다고 치자.
또는 특정 에러 종류에 따라 처리할 수도 있다.
이 경우 첫번째 소스는 에러 케이스가 10개든 100개든 찾아내어 고쳐야한다.
두번째 소스는 함수 하나의 수정으로 가능하다.

간단하지만 생각해서 적용하는게 아니라 자연스럽게 몸에서 베어나오도록 해야 한다.