프로토콜을 다루는 프로그램에서 가장 많이 사용되는 design pattern은 아마 State pattern일 것입니다. GoF의 State pattern 설명에서 Structure 부분을 보면 다음과 같습니다. (State pattern의 설명은 다들 아실테니 생략합니다.)
이번 글에서는 프로토콜을 다루는 코드 대신 Wikipedia에 있는 State pattern 코드를 가지고 설명하겠습니다. 이 예제는 drawing program에 대해서 다루고 있습니다. 먼저 Wikipedia에 있는 코드를 보시죠. 아래의 AbstractTool 클래스는 위의 State pattern의 Structure에서 State에 해당합니다. ((AbstractTool 클래스에는 public virtual 소멸자가 있어야 하나 Wikipedia에 있는 코드를 그대로 사용합니다.))
다음으로 ConcreateState에 해당하는 PenTool과 SelectionTool 클래스가 있습니다.
마지막으로 이 Tool들을 사용하는 DrawingController 클래스가 있습니다. 이는 GoF의 Structure중 Context에 해당합니다.
깔끔하게 State pattern이 적용된 것으로 보입니다. 물론 이 정도로 적당하다고 생각된다면 refactoring을 더 할 필요는 없습니다. 하지만 이번 글에서는 좀 더 나가 보도록 하겠습니다.
먼저 PenTool과 SelectionTool의 생성자를 비교해 볼까요?
다음으로 MouseDown 함수도 한번 비교해보죠.
마지막으로 멤버 변수들 차례입니다.
이제 뭔가 냄새가 나기 시작하죠? 바로 refactoring에서 말하는 Duplicated Code라는 bad smell입니다. 냄새를 맡았으니 뭔가 수정을 해야겠죠?
생각할 수 있는 간단한 수정 방법은 다음과 같습니다. 먼저 모든 Tool에서 공통으로 사용되는 멤버 변수들을 AbstractTool로 옮기고 AbstractTool의 pure virtual function에 default 구현을 제공합니다. 다음으로 PenTool과 SelectionTool에서 자신이 할 일을 하기 전에 AbstractTool의 구현을 호출합니다. 말은 복잡하지만 실제 구현은 다음과 같이 간단합니다.
먼저 수정된 AbstractTool입니다. ((멤버 변수들은 private으로 선언해야 하나 여기서는 예제 코드의 라인 수를 조금 줄이기 위해 protected를 사용했습니다. 실제 코드 작성시엔 멤버 변수는 무조건 private입니다. :-) )) AbstractTool의 MouseDown과 MouseUp이 구현을 제공하고 있습니다.
다음으로 수정된 PenTool과 SelectionTool 클래스입니다. 기존에 PenTool과 SelectionTool에서 중복되었던 코드들이 AbstractTool로 이동된 것을 볼 수 있습니다.
하지만 이 방법은 하나의 단점을 가지게 됩니다. 다른 사용자가 AbstractTool을 상속받아 구현할 때마다 어떤 규칙을 기억해야 한다는 것이죠. 그 규칙이란 MouseDown와 MouseUp 구현시 함수의 제일 처음에 AbstractTool의 함수를 먼저 호출해 주어야 한다는 것입니다.
이렇게 뭔가를 기억해야 한다는 것은 다음의 규칙을 어기는 것이 됩니다.
그럼 이 문제는 어떻게 해결해야 할까요? 여기서 사용할 방법은 바로 NVI (Non-Virtual Interface) Idiom입니다. NVI에 따르면 AbstractTool의 MouseDown이나 MouseUp같은 함수는 동시에 두가지의 역할을 하고 있습니다. 첫째는 interface 역할이고 두번째는 customizable behavior입니다. 따라서 이 역할을 분리해 주어야 하는데 이를 위해 다음과 같은 guideline을 제시하고 있습니다.
그럼 NVI를 사용해서 문제를 duplicated code를 다시 해결해 보죠.
이제 ConcreteTool들은 MouseUp같은 함수가 아닌 DoMouseUp과 같은 private 함수를 overriding해야 합니다.
이쯤에서 만족할 수도 있지만 여기까지 왔으니 refactoring의 끝까지 가보죠. ((여기까지 읽으신 분이라면 끝까지 읽으시겠죠? ;-) ))
먼저 NVI를 사용함으로써 interface와 customizable behavior가 분리되었으므로 분리된 두 함수는 signature가 같지 않아도 됩니다. 따라서 DoMoveTo에서 사용하는 mLastP와 같은 값은 함수의 인자로 넘어올 수 있습니다. 다음으로 DoMouseDown이나 DoMouseUp 함수의 경우에는 AbstractTool에서 해주는 것 이외의 작업이 필요 없는 경우가 있으므로 이 두 함수는 non-pure virtual 함수로 바꾸겠습니다. 마지막으로 DoMoveTo의 리턴 값을 Point로 바꾸고 이를 mLastP를 업데이트할 값으로 사용하도록 합니다. 물론 Point 대신 mLastP를 업데이트할지 여부를 나타내는 boolean 값이나 enum값을 정의하여 사용할 수 있습니다.
그럼 다시 수정된 AbstractTool 코드입니다.
이번 글에서는 State pattern에 NVI를 적용하여 Duplicated Code를 제거할 수 있는 방법에 대해 살펴 보았습니다. 사실 NVI의 guideline에 따르면 public virtual은 base class의 소멸자 선언에서나 볼 수 있어야 합니다. 물론 모든 경우에 이렇게 NVI를 적용하는 것은 무리가 있어 보이지만 클래스가 크면 클수록 NVI를 적용해야 할 필요는 더 커지는 것 같습니다. 클래스가 커질수록 interface 수정에 드는 비용 역시 커지기 때문이죠.
이번 글은 지난주에 회사에서 State pattern을 사용하는 프로토콜 관련 코드를 검토하던 중에 생각한 내용입니다. 물론 제가 봤던 코드 역시 NVI가 적용되어 있지 않았답니다. :-|
이번 글에서는 프로토콜을 다루는 코드 대신 Wikipedia에 있는 State pattern 코드를 가지고 설명하겠습니다. 이 예제는 drawing program에 대해서 다루고 있습니다. 먼저 Wikipedia에 있는 코드를 보시죠. 아래의 AbstractTool 클래스는 위의 State pattern의 Structure에서 State에 해당합니다. ((AbstractTool 클래스에는 public virtual 소멸자가 있어야 하나 Wikipedia에 있는 코드를 그대로 사용합니다.))
class AbstractTool {
public:
virtual void MoveTo(const Point& inP) = 0;
virtual void MouseDown(const Point& inP) = 0;
virtual void MouseUp(const Point& inP) = 0;
};
다음으로 ConcreateState에 해당하는 PenTool과 SelectionTool 클래스가 있습니다.
class PenTool : public AbstractTool {
public:
PenTool() : mMouseIsDown(false) {
}
virtual void MoveTo(const Point& inP) {
if(mMouseIsDown) {
DrawLine(mLastP, inP);
}
mLastP = inP;
}
virtual void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
}
virtual void MouseUp(const Point& inP) {
mMouseIsDown = false;
}
private:
bool mMouseIsDown;
Point mLastP;
};
class SelectionTool : public AbstractTool {
public:
SelectionTool() : mMouseIsDown(false) {
}
virtual void MoveTo(const Point& inP) {
if(mMouseIsDown) {
mSelection.Set(mLastP, inP);
}
}
virtual void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
mSelection.Set(mLastP, inP);
}
virtual void MouseUp(const Point& inP) {
mMouseIsDown = false;
}
private:
bool mMouseIsDown;
Point mLastP;
Rectangle mSelection;
};
마지막으로 이 Tool들을 사용하는 DrawingController 클래스가 있습니다. 이는 GoF의 Structure중 Context에 해당합니다.
class DrawingController {
public:
DrawingController() { selectPenTool(); } // Start with some tool.
void MoveTo(const Point& inP) { currentTool->MoveTo(inP); }
void MouseDown(const Point& inP) { currentTool->MouseDown(inP); }
void MouseUp(const Point& inP) { currentTool->MouseUp(inP); }
void selectPenTool() { currentTool.reset(new PenTool); }
void selectSelectionTool() { currentTool.reset(new SelectionTool); }
private:
std::auto_ptr currentTool;
};
깔끔하게 State pattern이 적용된 것으로 보입니다. 물론 이 정도로 적당하다고 생각된다면 refactoring을 더 할 필요는 없습니다. 하지만 이번 글에서는 좀 더 나가 보도록 하겠습니다.
먼저 PenTool과 SelectionTool의 생성자를 비교해 볼까요?
// PenTool
PenTool() : mMouseIsDown(false) {
}
// SelectionTool
SelectionTool() : mMouseIsDown(false) {
}
다음으로 MouseDown 함수도 한번 비교해보죠.
// PenTool
virtual void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
}
// SelectionTool
virtual void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
mSelection.Set(mLastP, inP);
}
마지막으로 멤버 변수들 차례입니다.
// PenTool
bool mMouseIsDown;
Point mLastP;
// SelectionTool
bool mMouseIsDown;
Point mLastP;
Rectangle mSelection;
이제 뭔가 냄새가 나기 시작하죠? 바로 refactoring에서 말하는 Duplicated Code라는 bad smell입니다. 냄새를 맡았으니 뭔가 수정을 해야겠죠?
생각할 수 있는 간단한 수정 방법은 다음과 같습니다. 먼저 모든 Tool에서 공통으로 사용되는 멤버 변수들을 AbstractTool로 옮기고 AbstractTool의 pure virtual function에 default 구현을 제공합니다. 다음으로 PenTool과 SelectionTool에서 자신이 할 일을 하기 전에 AbstractTool의 구현을 호출합니다. 말은 복잡하지만 실제 구현은 다음과 같이 간단합니다.
먼저 수정된 AbstractTool입니다. ((멤버 변수들은 private으로 선언해야 하나 여기서는 예제 코드의 라인 수를 조금 줄이기 위해 protected를 사용했습니다. 실제 코드 작성시엔 멤버 변수는 무조건 private입니다. :-) )) AbstractTool의 MouseDown과 MouseUp이 구현을 제공하고 있습니다.
class AbstractTool {
public:
AbstractTool() : mMouseIsDown(false) {
}
virtual void MoveTo(const Point& inP) = 0;
virtual void MouseDown(const Point& inP) = 0 {
mMouseIsDown = true;
mLastP = inP;
}
virtual void MouseUp(const Point& inP) = 0{
mMouseIsDown = false;
}
protected:
bool mMouseIsDown;
Point mLastP;
};
다음으로 수정된 PenTool과 SelectionTool 클래스입니다. 기존에 PenTool과 SelectionTool에서 중복되었던 코드들이 AbstractTool로 이동된 것을 볼 수 있습니다.
class PenTool : public AbstractTool {
public:
PenTool() {
}
virtual void MoveTo(const Point& inP) {
if(mMouseIsDown) {
DrawLine(mLastP, inP);
}
mLastP = inP;
}
virtual void MouseDown(const Point& inP) {
AbstractTool::MouseDown(inP); // call base implementation
}
virtual void MouseUp(const Point& inP) {
AbstractTool::MouseUp(inP); // call base implementation
}
};
class SelectionTool : public AbstractTool {
public:
SelectionTool() {}
virtual void MoveTo(const Point& inP) {
if(mMouseIsDown) {
mSelection.Set(mLastP, inP);
}
}
virtual void MouseDown(const Point& inP) {
AbstractTool::MouseDown(inP); // call base implementation
mSelection.Set(inP, inP);
}
virtual void MouseUp(const Point& inP) {
AbstractTool::MouseUp(inP); // call base implementation
}
private:
Rectangle mSelection;
};
하지만 이 방법은 하나의 단점을 가지게 됩니다. 다른 사용자가 AbstractTool을 상속받아 구현할 때마다 어떤 규칙을 기억해야 한다는 것이죠. 그 규칙이란 MouseDown와 MouseUp 구현시 함수의 제일 처음에 AbstractTool의 함수를 먼저 호출해 주어야 한다는 것입니다.
이렇게 뭔가를 기억해야 한다는 것은 다음의 규칙을 어기는 것이 됩니다.
A well written code-module is easy to use correctly and difficult to use wrong.
그럼 이 문제는 어떻게 해결해야 할까요? 여기서 사용할 방법은 바로 NVI (Non-Virtual Interface) Idiom입니다. NVI에 따르면 AbstractTool의 MouseDown이나 MouseUp같은 함수는 동시에 두가지의 역할을 하고 있습니다. 첫째는 interface 역할이고 두번째는 customizable behavior입니다. 따라서 이 역할을 분리해 주어야 하는데 이를 위해 다음과 같은 guideline을 제시하고 있습니다.
- Prefer to make interfaces nonvirtual, using Template Method.
- Prefer to make virtual functions private.
- Only if derived classes need to invoke the base implementation of a virtual function, make the virtual function protected.
그럼 NVI를 사용해서 문제를 duplicated code를 다시 해결해 보죠.
class AbstractTool {
public:
AbstractTool() : mMouseIsDown(false) {}
void MoveTo(const Point& inP) { // interfaces are nonvirtual
DoMoveTo(inP); // Template Method
}
void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
DoMouseDown(inP);
}
void MouseUp(const Point& inP) {
mMouseIsDown = false;
DoMouseUp(inP);
}
private:
virtual void DoMoveTo(const Point& inP) = 0; // virtual functions are private
virtual void DoMoveDown(const Point& inP) = 0;
virtual void DoMoveUp(const Point& inP) = 0;
protected:
bool mMouseIsDown;
Point mLastP;
};
이제 ConcreteTool들은 MouseUp같은 함수가 아닌 DoMouseUp과 같은 private 함수를 overriding해야 합니다.
class PenTool : public AbstractTool {
public:
PenTool() {
}
virtual void DoMoveTo(const Point& inP) {
if(mMouseIsDown) {
DrawLine(mLastP, inP);
}
mLastP = inP;
}
virtual void DoMouseDown(const Point& inP) {
}
virtual void DoMouseUp(const Point& inP) {
}
};
class SelectionTool : public AbstractTool {
public:
SelectionTool() {
}
virtual void DoMoveTo(const Point& inP) {
if(mMouseIsDown) {
mSelection.Set(mLastP, inP);
}
}
virtual void DoMouseDown(const Point& inP) {
mSelection.Set(inP, inP);
}
virtual void DoMouseUp(const Point& inP) {
}
private:
Rectangle mSelection;
};
이쯤에서 만족할 수도 있지만 여기까지 왔으니 refactoring의 끝까지 가보죠. ((여기까지 읽으신 분이라면 끝까지 읽으시겠죠? ;-) ))
먼저 NVI를 사용함으로써 interface와 customizable behavior가 분리되었으므로 분리된 두 함수는 signature가 같지 않아도 됩니다. 따라서 DoMoveTo에서 사용하는 mLastP와 같은 값은 함수의 인자로 넘어올 수 있습니다. 다음으로 DoMouseDown이나 DoMouseUp 함수의 경우에는 AbstractTool에서 해주는 것 이외의 작업이 필요 없는 경우가 있으므로 이 두 함수는 non-pure virtual 함수로 바꾸겠습니다. 마지막으로 DoMoveTo의 리턴 값을 Point로 바꾸고 이를 mLastP를 업데이트할 값으로 사용하도록 합니다. 물론 Point 대신 mLastP를 업데이트할지 여부를 나타내는 boolean 값이나 enum값을 정의하여 사용할 수 있습니다.
그럼 다시 수정된 AbstractTool 코드입니다.
class AbstractTool {
public:
AbstractTool() : mMouseIsDown(false) {}
void MoveTo(const Point& inP) {
mLastP = DoMoveTo(mMouseDown, mLastP, inP);
}
void MouseDown(const Point& inP) {
mMouseIsDown = true;
mLastP = inP;
DoMouseDown(inP);
}
void MouseUp(const Point& inP) {
mMouseIsDown = false;
DoMouseUp(inP);
}
private:
virtual Point DoMoveTo(bool isMouseDown, const Point& lastP, const Point& inP) = 0; // return Point
virtual void DoMoveDown(const Point& inP) {} // non-pure virtual
virtual void DoMoveUp(const Point& inP) {}
private: // changed to private because no derived class access these
bool mMouseIsDown;
Point mLastP;
};
class PenTool : public AbstractTool {
public:
PenTool() {}
virtual Point DoMoveTo(bool isMouseDown, const Point& lastP, const Point& inP) {
if(isMouseDown) {
DrawLine(lastP, inP);
}
return inP; // update lastP to inP
}
};
class SelectionTool : public AbstractTool {
public:
SelectionTool() {}
virtual Point DoMoveTo(bool isMouseDown, const Point& lastP, const Point& inP) {
if(isMouseDown) {
mSelection.Set(lastP, inP);
}
return lastP; // do not update lastP
}
virtual void DoMouseDown(const Point& inP) {
mSelection.Set(inP, inP);
}
private:
Rectangle mSelection;
};
이번 글에서는 State pattern에 NVI를 적용하여 Duplicated Code를 제거할 수 있는 방법에 대해 살펴 보았습니다. 사실 NVI의 guideline에 따르면 public virtual은 base class의 소멸자 선언에서나 볼 수 있어야 합니다. 물론 모든 경우에 이렇게 NVI를 적용하는 것은 무리가 있어 보이지만 클래스가 크면 클수록 NVI를 적용해야 할 필요는 더 커지는 것 같습니다. 클래스가 커질수록 interface 수정에 드는 비용 역시 커지기 때문이죠.
이번 글은 지난주에 회사에서 State pattern을 사용하는 프로토콜 관련 코드를 검토하던 중에 생각한 내용입니다. 물론 제가 봤던 코드 역시 NVI가 적용되어 있지 않았답니다. :-|
훌륭하십니다. 감탄했어요.
ReplyDelete