결론은 두번째 철학을 번역한 것입니다. 자세한 내용은 제가 올린 마지막 url을 참고해주세요.
상속에 대한 구현상속과 인터페이스 상속에 대해서 혼돈이 발생한것 같습니다. gof 책에서는 클래스 상속은 구현 상속을 말하는 것이었습니다. 클래스 상속은 interface 상속을 포함한 말이 아닙니다.
전혀 토론 내용이 다르게 흘러 갔습니다. 감사합니다. 하지만 inteface상속을 기반으로한 compostion은 필수적인 것입니다. 그 글은 gof erich gamma 글을 참고해 주세요. 감사합니다. http://www.artima.com/lejava/articles/designprinciplesP.html
그리고 제대로 아래 debate가 왜 잘 못된 것인지 이해하시고 싶다면, http://www.devpia.com/forum/BoardView.aspx?no=958&ref=958&page=1&forumname=and_free&stype= 의 글을 참고해 주세요 깔끔한 결론을 들으실수 있을 겁니다.
이글은 원문입니다. - 제가 예전에 올린 잘못된 글이니 참고하시길 바랍니다.
Design Patterns 이 책에 대한 가치는 많은 사람들에게 익히 들어왔을 것이다. 몇몇 학자들이 논하던 Pattern이라는 것을, 많은 프로그래머들을 위해 공개 했고, 고수들의 프로그래밍 노하우를 알수 있는 서적이었기 때문에. 발간 당시 많은 이를 놀라게 한 서적이었다.
이 책은 절대 여러번 읽으라고 권하고 싶은 책이다. 가능하다면 원서로 읽는 것이 더 도움이 될거라고 생각이 든다. 잘못된 오역이 있기 때문에.. 일단 내용이나. 전체적인 면에 대해서 설명하겠다.
처음 이 책은 일독 했을때는 현재 컴퓨팅 이슈와는 좀 시대적 차이가 있는 부분을 예제로 다루 었기 때문에, 당장 현재 실무에 쓰기에는 비 적합한 책이다. 이책의 출판년도가 1990년도라서 현재 2000년도의 이슈와는 동떨어진 면이 있다.
하지만 이 책의 진가는 여러번 읽었을대 그 깊이를 느낄수 있는 책이다. 일독을 마친 상태에서 다시 서두를 읽었을때는 전율을 느끼게 해 준 책이었다. 이 책의 서두의 철학은 객체 지향의 진정한 묘미이다.
Design Pattern의 두가지 철학이 있는데. 하나는 Program to an interface not to an implementation 이라는 언어이다. 프로그램을 직접 구현하는 것이 아니라. interface를 두어서 다형성을 확보하라는 것이 첫번재 철학이다.
그렇기 때문에 모든 design pattern은 항상 오른쪽에 추상 클래스와 추상 클래스를 상속받은 concrete class로 관계가 맺어진 것을 확인할수 있다. interface를 이용한 다형성의 확보라는 철학은 reuse라는 것에만 초첨이 맞추고 개발한 개발자에게 변화에 유연한 구조를 가지는 좋은 방법을 제안한 것이다.
두번째 철학은 Favor object composition over class inheritance이다. 하지만 이 번역서는 두번째 철학을 아주 엉뚱하게 번역했다. 아마 이것때문에 원서를 읽은 사람은 번역이 엉망이라는 말을 많이 한다.
실제 원서의 의미는 클래스 상속을 기반으로한 객체 조합을 선호해라 라는 의미이다. class inheritance는 컴파일 타임때 결정되어 run-time시에 상속을 받을수 없으므로 변화에 유여한 프로그램이 될수 없다. 하지만 가독성 객체 조합에 비해 증가하는 장점이 있다.
반면에 object composition은 런타임시 결정되지만, 런타임식에 모든 것이 결정되기 때문에. 객체의 상태나 관리, 또는 가독성이 떨어지게 된다. 그래서 이러한 문제를 해결하기위해 class inheritance를 기반으로한 객체 조합을 사용하라는 의미가 된다. 다시 말하자면 두번재 철학은 상속을 통한 다형성을 유지하여 변화에 유연한 프로그램을 만들고 compostion을 이용함으로써 재사용성을 극대화 하라는 메세지이다.
하지만 이 책은 design pattern 두가지 철학중 하나를 완전히 잘못 번역했다.
Favor object composition over class inheritance 를 객체 합성(조합)이 클래스 합성보다 더 나은 방법이다. (p24)라고 번역을 해 버렸다. 그렇기 때문에 앞뒤 문맥이 전혀 맞지 않고, 디자인 패턴을 처음 시작하는 이에게는 오해의 소지를 가져오고야 마는 큰 실수를 저지른 책이다.
그렇기 때문에 pattern에 대해서 원서를 읽어 본 사람들은 번역이 엄청나게 잘못되었다고 말을 하는 것이다. 가장 중요한 철학 두개중 하나를 잘못 번역했기 때문에, 초심자에게 잘못된 지식을 전파함으로써, 많은 문제를 야기시키게 된다. 물론 이책을 보되, 항상 원서와 같이 비판적으로 보는 것이 지식의 도움이 될것 같다.
비평을 한것 같아. 역자에게는 미안하지만, 올바른 지식을 전달하는 차원에서는 이것이 맞을것 같아 서평을 남긴다.
김병수2006-01-02 오전 11:13:58
Favor object composition over class inheritance. 직역하자면 "class inheritance보다 object composition을 선호해라"쯤 되지 싶군요. 그리 따지면 "객체 합성(조합)이 클래스 합성보다 더 나은 방법이다"라는 번역에서 클래스 상속을 합성으로 오역한 것이지 전체 의미를 잘못 전달한게 아닌게 되겠네요. 저자가 지적한 것은 불필요한 상속을 피하고 composition을 이용하란 의미 정도라고 봅니다.
김병수2006-01-02 오전 11:14:02
실제로 많은 프로그래머(초보부터 전문가까지)들이 상속을 은총알쯤으로 생각하던 풍토(90년대 초반?)에 대한 강한 경고로 보입니다. 그것을 손영수님께서 너무 확대해석을 하는게 아닌가 생각합니다.
손영수2006-01-02 오후 2:02:02
영어 원서 본문을 다시 읽어 보십시오 --;;; 교수님과 저희 Devpia A&D 동호회에서 토론을 한후 결정한 내용입니다. over를 기반으로 해석하는 것이 맞습니다. 원서 뒷부분을 읽어 보면 확실한 말이 있습니다. 이단락 마지막에 Inheritance and object composition thus work together. (상속과 객체 조합은 이와같이 함께 사용하는게 좋다) 라는 말이 있습니다.
손영수2006-01-02 오후 2:04:50
그리고 디자인 패턴의 어느 패턴이든지 상관없이 오른쪽 그림을 보면 상속을 기반으로한 조합을 사용하고 있음을 볼수 있습니다.
손영수2006-01-02 오후 2:05:58
이 책은 워낙 깊이가 있는 책이라 제가 섣불리 이런 글을 적을리 없습니다. 충분히 토론을 거쳤습니다. 토론의 자세한 내용은 http://www.devpia.com/Forum/BoardView.aspx?no=938&ref=938&page=1&forumname=and_free&stype= 로 가서 보시구요. 병수님의 말씀대로 하자면 favor 보다는 better를 쓰는게 맞습니다. devpia architecture & design sysop 손영수
류광2006-01-02 오후 3:41:32
클래스 상속을 클래스 합성이라고 한 것 이외에는 심각한 오역은 아닌 것 같습니다. 순수하게 번역의 측면을 보자면, favor ~ over ~는 일종의 숙어이고, over를 based로 해석하는 게 불가능한 용례들도 많이 있습니다. 만일 그 문장에서 over가 based를 뜻하는 것이었다면 저자가 잘못한 것이라고 보는 게 합당할 것입니다.
류광2006-01-02 오후 3:44:29
차라리 핵심은 '더 낫다'라는 우리말 표현을 어떻게 받아들이느냐가 되지 않을까 싶네요. 한 쪽을 버리라는 것이 아니라, 만일 한 가지 일을 합성으로도, 상속으로도 할 수 있다면 합성을 사용하라는 뜻으로 보는 게 좋을 것 같습니다. 합성과 상속을 섞어 쓰는(써야 하는) 경우가 많다는 것과 상속보다 합성을 선호하라는 것이 상호배제되는 것은 아니라고 봅니다.
류광2006-01-02 오후 3:44:52
글자 제한도 있고 해서 좀 불편하네요. 나중에 제 블로그에 좀 더 자세한 글을 올리고 여기에 URL을 남기겠습니다...
손영수2006-01-02 오후 8:34:06
원서를 읽어 보시길 바랍니다. 전혀 반대로 설명되어 있습니다. 이상적으로 조합만을 이용할 수 있는 경우는 극히 드물다. 그러므로 상속을 기반으로한 조합을 하라고 나와있습니다. 원서 20페이지를 참고해 주시길 바랍니다. 감사합니다
류광2006-01-05 오전 3:18:38
Nevertheless..로 시작하는 그 다음 문단이 더 결정적이지 않을까요. 어쨌든 ... 전에 말한 글 이제야 썼습니다. 주소는 http://occam.n4gate.com/tt/index.php?pl=88 입니다. 쓸데없이 길고 횡설수설이라 부끄럽지만 그래도 읽어주세요~
손영수2006-01-05 오후 8:26:12
결론을 정할수 있는 글입니다. ^^ gof를 직접 쓴 erich gamma의 interview 내용입니다. 다른 분들도 읽어 보시길 바랍니다. debate 끝 ^^ 싱거운 결론이군요 ^^ http://www.artima.com/lejava/articles/designprinciplesP.html
손영수2006-01-06 오전 1:58:49
원래 역자가 정확한 번역을 한것이 맞습니다. 모든 것이 저의 지식의 무지입니다. 자세한 내용은 제가 올린 내용을 참고해 주시면 됩니다. 감사합니다. http://www.devpia.com/forum/BoardView.aspx?no=958&ref=958&page=1&forumname=and_free&stype= 결론은 역자가 맞는 것입니다. 그런데 뭔가 심오한 것이 있으니 한번 봐주세요 ^^ 감사합니다
손영수2006-01-06 오후 2:42:50
클래스 상속이라는 것보다는 구현 상속(subclassing)이라고 하는 것이 오해의 여지를 줄일수 있는 방법이 아닌가 봅니다.
김현철2008-04-15 오후 1:35:04
책은 어차피 정의가 아니라 한사람의 의견일뿐인데 독자들이 보는데로 다 믿는건 아니니까 그리 심각할 필요는 없는것같네요. 어차피 프로그래밍이 철학적인 단계로 넘어가면 프로그래머들은 각자의 철학을 가지고 있을테니.. 남들이 이게 좋으니 그리해라한다고해서 무조건 그렇게 하는것은 아니지요. 자기 편한데로의 문법이나 방식등은 다 각자 가지고 있으니까요.
