다중 상속 어떻게 생각하세요?
홍민희다중 상속(multiple inheritance), 어떻게 생각하세요? 다이어몬드 문제가 있다고는 하지만, 저는 그게 다중 상속의 장점을 버릴 정도로 큰 문제라고 생각하지 않거든요. Java 등 언어에서의 인터페이스(inteface) 기능은 때때로 부족할 때가 있어요.
풍성한 답변을 기다리고 있겠습니다. ㅋㅋ
다중 상속(multiple inheritance), 어떻게 생각하세요? 다이어몬드 문제가 있다고는 하지만, 저는 그게 다중 상속의 장점을 버릴 정도로 큰 문제라고 생각하지 않거든요. Java 등 언어에서의 인터페이스(inteface) 기능은 때때로 부족할 때가 있어요.
풍성한 답변을 기다리고 있겠습니다. ㅋㅋ
대략 다중상속에 대한 생각은...
자바 interface에 대한 생각은...
냠... 스몰톡과 마찬가지로 공통된 어휘를 갖고 있는 클래스를 구분하기 위한 것이며, 스몰톡이 다이나믹 언어였다면 강성형 언어의 특징을 갖고 있는 자바로서 인터페이스는 특정 타입의 시그내쳐를 다수 포함할 수 있도록 해주는 의미외에는 없답니다. 메서드 시그내쳐를 갖고 다닌다고해서 메서드 구현을 공유하는것은 아니지요. 같은 맥락에서 스몰톡 또한 단일상속만을 지원하지만 이에 대해서 입에 거품을 무는 사람은 별로 보지 못한 것 같아 아쉽...
떡밥이 좀 쉰것 같다는 생각이 든다능... 21c에 어울리는 신선한 떡밥은 뭐가 있을지 궁금하다능...
대략 소인 생각으로는 "객체들의 섬" 문제등으로 말해지는 객체의 재사용성에 대한 문제로 시작해서 erlang의 oop-less한 모습도 그다지 불만스럽지 않음을 조명하고, 다시 haskell의 타입시스템(흔히 말하는 상속이니 인스턴스니 클래스니 하는 oop랑은 거리가 멀고)을 살펴보고 차라리 더 타입시스템으로 더 완전한을 보이고, 최근의 perl6등에서 적극적으로 이를 도입하는 모습등을 조명하며 현재 oop한다는 사람들이 사실은 class-based oop을 한다는것을 지적하며 그 본질과는 관계없이 현학적이기만하고 실세계의 문제와는 멀어져만 가며 결국 소프트웨어위기의 가장 큰 적은 다름아닌 그러한 관점이라고 지적하는게 훨씬 신선한 떡밥이 아닐까 생각해봄.
Traits가 있지 않습니까. :)
지식이 미천하여. 잘은 모르겠지만 :-) 상속 자체가 코드 압축 기법이 아닌가 합니다.(Subclassing의 경우)
상속의 깊이가 깊을 수록(상속에 관한 관계가 많아질수록) 현재 코드 전개 뒤에서 일어나는 일들이. 명시적으로 보이지 않아서 프로그램이 변화에 대처하기에 갈수록 어려워지지 않나 싶습니다..
SubTyping의 경우 자바의 인터페이스는 다형성을 추구하는 방편으로 사용되지만(특히 책에서.) 상속으로 하면 쉽게 갈수 있는 것을 오히려 할 일이 많이 하게 해서... 다른 면에서 복잡도가 증가되는 편인거 같기도 하고..
하지만 상속에 대한 제한을 많이 열어두지 않는 편이 좋다고 생각합니다. (흠. 기승전결이 제각각이군요. 어쩜 조아.ㅋㅋ;;;)
맹수>> 그래서 oop은 goto을 사용하지않고 스파게티 코드를 만드는 방법이라고도 하지요. ^^;
소프트웨어를 작성하는 과정을 실세계에 대한 모델링이라고 생각할때, 다중상속을 지원하지 않는 언어는 인식론적인 관점에서 사고를 환원주의적인 방향으로 제한하는 냄새를 풍깁니다.
A is B and A is C 같은 상황은 표현하기 힘들어지지요.
환원할 수 없는 것을 환원시켜야만 하는 상황은 가능하면 피하고 싶어집니다. 다중상속의 존재는 "반드시" 있어야 하는 것이지만, "왠만하면" 피해야하는 것이라고 봅니다.
다이아몬드 문제는 C3 알고리즘을 쓰면 해결되니 괜한 트집이라고 생각합니다.
보통의 개발자는 상속이 꼬이면 힘들어합니다. Java는 보통사람들을 위한 언어거든요. 솔직히 상속안해도 힘들어하죠--;
다중 상속이 문제가 되는건 프로그래머들이 대부분 귀차니즘에 찌들어 있어서 나중에 좀 복잡하게 될 것 같아도 당장에 편하게 가려는 경향이 있기 때문이 아닐까 합니다.
ps. 아무리 뛰어난 사람도 쓸데없이 복잡하기만한 코드를 디버깅하면서 시간낭비 하고 싶어하지 않기 때문에 Java가 보통사람들을 위한 언어 라는건 비유는 좀 그렇구...
제한 없는 기능들을 얼마나 심플하고 직관적 으로 활용할 수 있느냐 없느냐가 보통사람과 그렇지 않은 사람을 구분하는게 아닐까 싶네 요. (그냥 사용하는건 누구나 할 수 있으니까요..)
제 얕은 경험에 의하면 고수일수록 문제를 간단하게 해결합니다. 정확히 말해서 문제 도메인 자체를 최대한 간단하면서도 직관적인 관점으로 바라보는 것 같습니다. 따라서 그걸 구현하는 코드의 메타포도 상당히 짧고, 간결하며, 직관적입니다.
다중 상속이 문제가 된다면 그걸 가지고 복잡하게만 써서, 복잡하게 만들어버리는 사람들 때문이 아닐까 생각합니다. 하지만 그런 사람들한테는 다중 상속 말고 뭘 줘도 똑같습니다. Java에 다중 상속이 없지만, 그렇다고 또 Java로 짠 코드 대부분이 간결한가요? 문제를 복잡하게 만드는 것은 사람이지 다중 상속이라는 일개 기능이 아니라고 생각해요.
네 맞는 말씀이십니다. 또 문제가 되는건, 실제로 뛰어난 분들일지라도 머리로 알고 있는 것을 실천하는 분이 드물다는 점이기도 하죠... ^^;
현실적으로 다중상속을 잘써서 얻는 이점과 다중상속을 잘못써서 얻는 단점을 놓고 봤을때...
다중상속을 잘써서 얻는 이점을 포기하면서라도 잘못써서 생기는 단점을 최소화하는게 더 이득인 경우가 많아서 되도록이면 피하려고 하는게 아닐까 하고 생각을 해봅니다. :)
정확히 말하자면 다중 상속은 이점이 없습니다. 그 구현결과가 델리게이트하는거랑 차이가 없을 뿐더러 단점은 훨씬 많습니다. 상속의 이점은 타입체킹을 우회하거나 다형성을 가져야 생기는 것인데, 타입체킹은 인터페이스만 상속해도 벗어나는 것이 가능하고, 다중상속에서는 오히려 다형성에서 문제가 생겨버립니다. 결국 안쓰는게 답입니다. 기존의 언어가 다중상속을 지원하고 있는 대부분의 이유는 개발자가 그렇게 문제가 될 줄 "몰라서" 넣은 것입니다. 그것이 아니라면 언어를 복잡하게 만드는 것이 힘드니 "알아서" 잘쓰라고 한 것이구요.
동의하지 않습니다.
이런 부분들이 고려될 부분이겠죠.
글쎄요. 제가 공부하던 때가 5년이나 흘러서 어쩌면 무언가 많이 바뀌었는지 의심이 가는군요. 지금 말씀하신 부분에 대해서 들어본 적이 없어서 그에 대한 걸 보려고 하면 어떤 부분을 찾아보면 될까요?
링크나 책을 추천해주시면 한번 찾아보도록 하겠습니다.
가장 읽어볼만한 책은 Modern C++ Design이라고 생각합니다.
Policy based programming은 다중상속을 의도적으로 활용하는 가장 즐거운 사례이지요. :)
Policy based programming은 다중 상속에서 당연히 문제가 생기지 않습니다. 설사 두 개의 클래스가 구현을 가지고 있더라도, 각자 다른 일만을 하기 때문에, 즉, 서브 클래싱이 아니라 서브 타이핑에 해당하기 때문에 올바른 사용법이 맞습니다.
이것은 애초에 논의되던 다중 상속의 문제를 "알아서 잘 쓰는" 방법이지, 다중상속을 써도 된다는 증거는 되지 못합니다. 제가 알고 싶은 것은 씨에님이 너무나도 다중상속을 써도된다고 단정적으로 말씀하시기에 그동안 혹시나 정말 다중 상속의 기술적인 문제가 해결되었는지 알고싶어서였습니다.
다시 정리하자면, 서브 타이핑과 서브 클래싱을 구별해서 쓰면 다중 상속의 문제가 발생하지는 않습니다. 이것은 "알아서 잘 쓰는" 방법이지 다중 상속을 써도 된다는 증거가 아닙니다. 제가 알고 싶은 것은 정말 다중 상속의 "문제가 해결되었는지"에 대한 것이지요.
저는 다이아몬드 문제들이 C3 알고리즘을 비롯한 여러 방법을 통해해결되었다고 생각합니다. 저는 이 정도면 충분하다고 생각하는데 semmal님이 다르게 생각하시다면 거기에 대해 얘기를 나누면 될 것 같습니다.
다중 상속의 기술적인 문제를 모두 해결했다라는 말을 저는 어떤 언어에서는 다중 상속을 아무렇지 않게 써도 전혀 문제가 발생하지 않는다는 말로 받아들였습니다.
만약에 특정한 알고리즘이나 방법을 써서 다중상속의 단점을 피해야 한다면, 결국 다중 상속을 쓰지 않는 것이 좋다는 말이 되겠지요.
문제를 피하는 방법만이 있을 뿐, 효과적으로 쓰는 방법이 없으니까요.
이론적으로는 서브타입 관계와 서브클래스 관계만 지켜주면 전혀 문제가 발생하지 않습니다. 이것은 수학적인 것이니까요. 저는 내심 내부적인 증명을 통해서 다중 상속을 안쓰도록 잡아주는 컴파일러라도 나온줄 알았습니다. 흐~
Java 위주로 하고 아직까지 실력이 부족해서 그런지 다중상속의 필요성을 느낀 적이 없었던 것 같아요~