알기 쉬운 디자인 패턴

+ 알기 쉬운 디자인 패턴

정   가 : 15,000원
저   자 : 알란셀로웨이/제임스 트로트
역   자 : 김유리,정지훈,이형로
출판사 : 피어슨에듀케이션코리아
페이지 : 326쪽
구입년도 : 2006. 3월.

최근에 구입한 책이다. 이것 외에 한권 더 샀는데, 일단 지금 보고 있는 책이다.
기존에 내가 사용하던 디자인들..그것의 정의와 분석.. 반쯤 읽었지만 아직 뭔가 허전한 느낌이다.
그것이 무엇인지 잘 생각해보니 그것은 바로 데이터의 흐름인것 같다.

각 클래스끼리 어떻게 서로의 데이터를 주고 받을껏인지..그리고 책에서 말하는 "책임전가"는 어떻게 이루어지는 것인지...무척 복잡한 관계이다.
책에서는 한 객체는 한개의 책임을 가져야 하는걸로 설명한다.

즉 main 함수가 draw객체를 쓴다면 "무엇을 그릴껀지" 알어야할 책임이 생기는 것이다.
그러나 실제로 실무에서는 단순히 이런 구조가 아니다. 더욱 복잡해지고 더 몇단계의 데이터이기 때문이다.draw 앞에 Hero가 있다고 치자. 그리고 UI가 있다. 이렇게 3개의 객체가 있다. 물론 UI도 draw를 가지고 있다. 이 3개의 데이터 흐름은 무척 강한 응집력을 갖기 쉽다.

Hero와 UI는 공통적으로 draw를 쓰게 되지만, UI는 Hero의 정보가 필요하다. UI가 사용할 draw는 Hero의 정보를 화면에 보여주는 디스플레이다.
하지만 UI는 독립적이게 되어야 한다. 물론 이 책에서의 예도 이런 정도의 구조이다.

이런걸 해결하기 위해 여러가지 패턴을 설명하고 해결책을 설명하지만....실제로 쓸때는 이런 경우가 단순히 위에 처럼 1차원에 걸쳐서 생기는 것이 아니라, 각 연관된 클래스들끼리 복합적이고 몇차원적으로 계속 겹치게 된다.

다리패턴 부분을 보고 있는데 그것이 이러한 부분을 해결해줄 꺼라 생각이 되긴 하다.
그러나 디자인 패턴은 말 그대로 패턴일 뿐이지 데이터의 흐름을 컨트롤 하진 못한다.
draw 객체 입장에선 Hero의 정보가 필요하고 UI 입장에서도 Hero의 정보가 필요하다.

그렇다면 결국 중복적인 부분이 생기게 되는것 아닌가? UI는 Hero가 가지고 있어야 하는 것일까??
Hero 보다 한단계 위에는 분명 GameMain 이라던가 하는 큰 분류가 있을것이다.
차원적으로 보면 (레벨개념) UI나 Hero나 같은 레벨이다. 그렇다면 Hero가 UI를 갖는다는 것은
설계상을 볼때 화살표가 평행으로 그어지는 엽기적인 부분이 된다고 본다.

         [ Main ]
     ↙             ↘
[  UI  ] ---> [ Hero ]
    ↓                ↓
[ ui2 ]          [ 주인공 ]
      ↘         ↙
        [ draw ]

거 참 무척 지저분한 설계다 -_-;; 무엇보다도 같은 레벨에서 UI -> hero를 평행으로 긋는것과
draw를 같이 사용하게 되는 부분이다.
이 책에서 현재 이런 설계에 대한 해답으로는 어뎁터 패턴과 다리패턴의 혼합을 제시 하고 있으나

내가 이야기한 UI -> Hero 평행은 설명하지 못하고 있다.
물론 위 처럼 단순한 문제는 다리 패턴을 이용해서 UI를 때어 내면 된다. 그러나 내가 가장 골치 아프게 생각하는 부분인 데이터의 중복이다.

때어 낸다 하더라도 히어로나 UI, draw객체에서 필요하는 정보의 중복이 많이 있게 되는 것이다.
이것은 서로의 응집력이 낮아 질수록, 즉 각 객체가 독립적일 수록 정보의 중복이 커진다.
응집력이 높다면, 그저 상속으로 해결이 되기 때문이다.

그러나 상속은 데이터를 단순화 시킬순 있지만 설계를 꼬아버릴수도 있으므로 남발해선 안된다.

뭐 어쨌든 어려운 문제다~

이러한 문제가 있으면서도 "요구 사항은 항상 변경된다. 그러므로 유연성이 높게 만들어야 한다"
라니.....허허~