C++ of the Day #34 - dynamic visitor 2

이번 글에서는 지난번 글에서 살펴보았던 dynamic visitor를 개선해 보도록 하겠습니다. 먼저 이전 구현에서 불편한 점을 알아보겠습니다.


struct B {}
struct D1 : B {}
struct D2 : B {}

void print(D1* ) { cout << "D1n"; }
void print(D2* ) { cout << "D2n"; }


이전과 같은 B, D1, D2 클래스가 있습니다. 달라진 점은 print라는 함수가 D1과 D2 클래스에 대해 이미 존재한다는 점입니다.

이 클래스들을 가지고 dynamic_visitor를 사용하면 다음과 같습니다.


typedef mpl::vector TL;

struct PrintVisitor : dynamic_visitor
{
void visit(B* b) { cout << “Bn”; }
void visit(D1* b) { cout << “D1n”; }
void visit(D2* b) { cout << “D2n”; }
};


여기서 문제는 이미 D1, D2에 대해 print라는 함수가 구현되어 있는데 PrintVisitor에서 다시 구현해야 한다는 점입니다. 물론 이 예제에서는 코드가 짧아 별 문제 없어 보이지만 긴 코드라면 문제가 됩니다. DRY 규칙에 어긋나는 것이죠. ((Don't Repeat Yourself.))

그럼 이번 글에서 살펴볼 개선된 dynamic_visitor의 사용법을 보겠습니다.


typedef mpl::vector TL;

struct PrintVisitor : dynamic_visitor
{
PrintVisitor() {
assign_impl(print);
assign_impl(print);
}
void visit(B* b) { cout << “Bn”; }
};


만약 base 클래스인 B 클래스에 대한 visit함수가 아무 일도 안해도 된다면 다음과 같이 using을 사용하여 B*에 대한 visit 함수 대신 dynamic_visitor가 제공하는 default 구현을 사용할 수 있습니다.


typedef mpl::vector TL;

struct PrintVisitor : dynamic_visitor
{
using super_t::visit;

PrintVisitor() {
assign_impl(print);
assign_impl(print);
}
};


여기서 super_t 타입은 dynamic_visitor에서 제공하는 typedef입니다. 만약 이 super_t 타입이 없다면 다음과 같이 코드가 복잡하고 길어지겠죠?


using dynamic_visitor::visit;


그럼 이제 구현에 대해 살펴보겠습니다.


template
class dynamic_visitor
{
typedef typename mpl::back::type base_type;

private:
template
struct visit_impl // (1)
{
typedef Ret (*impl_type)(T*);
visit_impl(impl_type it = 0) : impl(it) {}
impl_type impl;
};

typedef typename mpl::inherit_linearly<
TL,
mpl::inherit<_1, visit_impl<_2> >
>::type impl_map; // (2)

template
typename visit_impl::impl_type& get_impl(visit_impl& t) // (3)
{
return t.impl;
}

impl_map map_;

protected:
typedef dynamic_visitor super_t; // (4)

virtual Ret visit(base_type* ) {} // (5)

template
void assign_impl(typename visit_impl::impl_type impl) // (6)
{
get_impl(map_) = impl;
}

public:
Ret operator()(base_type* b) {
return do_visit(b, mpl::false_());
}

private:
template
Ret do_visit(base_type* b, mpl::false_) {
typedef typename mpl::front::type Head;
typedef typename mpl::pop_front::type Tail;
typedef typename mpl::empty::type IsEmpty;

Head* p = dynamic_cast(b);
if (p != 0) {
if (get_impl(map_)) { // (7)
return get_impl(map_)(p);
}
return static_cast(this)->visit(p);
}

return do_visit(b, IsEmpty());
}

template
Ret do_visit(base_type* b, mpl::true_) {
std::cout << "assertn"; // handle error.
return Ret();
}
};


각 항목 번호는 위의 코드에 있는 주석에 있는 번호에 해당합니다.


  1. function pointer를 저장하고 있는 클래스로 T 타입에 대해 Ret (T*) 함수 포인터를 저장한다.

  2. TypeList에 있는 타입들을 멤버 변수로 가지는 클래스를 선언한다. 여기서 inherit_linearly는 mpl 라이브러리에서 제공하는 meta-function으로 각 타입을 가지는 클래스들을 차례대로 상속받도록 fold하여 result 타입엔 각 타입에 해당하는 값을 가지고 있게 만들어 준다. ((예를 들어 만약 TL이 mpl::vector이라면 다음과 같은 클래스 hierarchy가 만들어집니다.

    struct visit_impl : empty_base { Ret (*impl)(char*); };
    struct visit_impl : visit_impl { Ret (*impl)(int*); };
    struct visit_impl : visit_impl { Ret (*impl)(double*); };

    ))

  3. 2번에서 만든 타입에서 특정 타입을 키로 하여 값을 얻을 수 있도록 해주는 helper function이다.

  4. 위에서 살펴 봤던 super_t 타입을 typedef한다.

  5. base 클래스에 대한 기본 visit 구현을 제공한다. 하위 클래스에서 using super_t::visit;를 하면 이 함수가 하위 클래스에서 보이게 된다.

  6. 하위 클래스에서 구현 함수를 셋할 수 있도록 해주는 protected 함수이다.

  7. 실제 operator() 호출시 사용자에 의해 셋된 구현이 있는지 확인하고 있다면 그 함수를 호출한다. 없다면 이전 버전과 동일하게 사용자가 구현한 visit 함수를 호출한다.



이외에 이전 글의 dynamic_visitor에 비해 개선된 점은 원하는 리턴 타입을 사용자가 지정할 수 있다는 점입니다. 예를 들어 추가하고자 하는 함수가 char const*를 리턴해야 한다면 다음과 같이 할 수 있습니다.


char const* get_name(D1* ) { return "D1"; }

typedef mpl::vector TL;

struct PrintVisitor : dynamic_visitor
{
char const* visit(B* ) { return "B"; }
char const* visit(D2* ) { return "D2"; }
};

// usage
PrintVisitor pv;
cout << pv(b1) << endl;
cout << pv(b2) << endl;


이번 글에서는 개선된 dynamic_visitor에 대해 알아봤습니다.

개인적으로는 남들이 사용할 수는 있지만 수정할 수 없는 라이브러리 코드에서 사용하는 것 외의 상황에서 Visitor 패턴을 만들어 사용하는 것을 권장하지 않습니다. 한번 프로젝트에서 사용했다가 크게 후회했던 적이 있거든요. 사실 제가 수정할 수도 있는 코드였는데 괜히 이 디자인 패턴을 사용해 봤던 것이죠. 덕분에 기능 추가할때마다 Visitor를 구현해야 했고 디버깅시 trace도 꽤나 복잡해지더군요. 물론 코드 읽기도 어려워지고요.
그리고 라이브러리 코드라고 해서 항상 코드를 수정할 수 없는 것은 아니라는 점도 고려해서 기능 확장을 위해 Visitor가 필요한지 그냥 코드를 수정하게 할지를 결정해야 할 것 같습니다.

Downloads



dynamic_visitor.zip

Comments

Popular Posts