Small Steps Blog

스몰토크 까페에서 간단히 네트웍369게임을 만들어보았습니다. 그 와중에 '프락시' 얘기가 나와서 한동안 출퇴근 길에 프락시를 고민했었습니다. 고민이라고 해봐야 별거 아니지만, ..

투명성

달룟 님 글에 댓글을 달면서 '일반적으로 프락시라고 하면 '투명성'을 가지고 있어야 한다' 라고 했습니다. 어차피 이런 설계들은 쓰임새로부터 생겨난 것들이라 정답이라는 게 있을 수는 없지만 '일반적으로' 그렇다는 거죠 ^^ http://en.wikipedia.org/wiki/Proxy_pattern

예를 들자면, 달룟 님의 코드에서 발견되는 remote proxy의 경우 Player는 Judge와 message를 주고받지만 사실 이 message는 socket을 타고 다른 곳에 있는 Judge로부터 값을 가져오죠. 하지만 Player는 이를 신경쓰지 않습니다.

투명성 어디까지?

하지만 Java, Smalltalk, Ruby 등.. 모든 클래스 들이 Object에서부터 시작하는 순수(?) 객체지향언어들에서는 과연 어디까지 투명성을 갖춰야 할것인가 생각해보니 헷갈리더군요.

과연 정말 client code가 구분할 수 없는 투명성을 갖출수 있을까? 갖추는 것이 맞을까?

Object class가 제공하는 interface는 어떻게 해야 할까요? 이것들마저 delegate시켜야할까요?

(C++에서는 모든 클래스의 공통 부모 클래스가 없어서 오히려 이문제로부터는 자유롭네요. 순수하지 못하죠? ^^)

경험

객체지향에 맛들이고, 디자인패턴을 알게되고 나서는 이러한 투명한 인터페이스에 다소 집착했던것 같습니다. 바로 이것이야 말로 '묘미'가 아닌가 하는 생각을 했었죠.

Image를 로딩해야 한다고? 그건 표준예제잖아! 당연히 proxy image를 써야지.

Remote 객체와 통신할때는 Proxy를 만들어서 위치투명성을 갖추야해. 이봐, 코드가 아름답잖아.

이렇게 혼자 도취되어 있다가 자주 막다른 길을 만났습니다. 다른 것은 다르게 표현하는 것이 여러모로 도움을 줄때가 많았습니다. client 모르게 슬쩍 알아서 처리해주는것이 깔끔할 때가 많지만, client 에게 '사실'을 알리고 협력하는 모델이 필요한 때도 있다는 거죠.

이 부분은 사실 조심스럽네요.. 객체지향이 '추상화'를 밑바탕에 깔고 있기 때문에 이에 반하는 이야기같기도 하고.

새로운 문제

프락시를 만들되 어떻게 하면 적절한 수준의 투명성을 제공하느냐. 어떻게 드러낼수 있는가?

예를 들자면, C++에서 shard_ptr 종류의 스마트포인터도 일종의 Proxy인데, operator. 을 사용하는 경우에는 Proxy Object를 사용하는 것이고, operator->을 사용하는 경우에는 Real Object를 사용하는 것이랍니다.

void foo( shared_ptr<Judge> judge )
{
  judge.xxx();
  judge->yyy();
}

쌩뚱맞은 마무리

앞으로 프락시 하나 만들때도 따져볼게 더 늘어나기만 한것 같습니다. ㅠ.ㅠ