[💬] 상속(인헤리턴스) vs 컴포지션 (구성)

[123123(121.150)]

상속과 구성은 약간 다르지만 비슷한 역할을 한다고 보면 됨.

둘다 추상화를 하면서 생긴 개념이고, 게임 만들때 중요하게 이용됨.

상속만 써라, 구성만 써라 이런건 아니지만 적절하게 이용하는게 중요하다고 생각함.

아래 예는 내가 처음으로 C++ 배웠을때 본 상속에 관한 예제임.

struct point2

{ 

 float x;

 float y;

}

stuct point3

{

 float x;

 float y;

 float z;

}

이렇게 2차원에 대한 점 클래스와, 3차원에 대한 점 클래스있음. 

또 다르게 구현하는 방법은 

struct point3_composite

{

  point2 xy;

  float z;

}

이렇게 구현함.

첫번째 방식은 서로 연관이 하나도 없는 별개의 클래스 2개고, 

2번째 방식은 컴포지션으로 구현한 3차원 점 클래스임.

여기서 생겨난 개념이 상속이란 개념임. 

상속을 써서 구현을 한다면 이렇게 구현이 될수 있음.

struct point3_inherit : public point 2

{

 float z;

}

C++ 내부에서 돌아가는 개념이 중요한게 아니니 후딱 넘어가고

상속과 컴포지션의 간단한 차이는 하나임.

컴포지션은 내가 가진 옷, 시계, 휴대폰 같은 가질수 있는것이고,

상속은 내가 사람이다, 동물이다, 라는 XX 이다의 개념임.

그래서 UML을 보면 상속은 is a 라는 강한 묶음이고, 컴포지션은 has a 라는 약한 묶음임.

기본적인 개념은 이렇고, 게임엔진으로 되돌아가면 상속과 컴포지션은 이런식으로 구현됨.

게임에서 수 많은 객체들이 있는데, 구현해야할 객체중에

좀비라는 객체와 뱀파이러라는 객체, 인간이라는 객체 이런식으로 있다고 하면

좀비와 뱀파이어는 몬스터니까 몬스터란 클래스를 상속하고, 인간은 그냥 인간 클래스를 상속하면 됨.

간단하게 그 개념을 그려보면 이렇게 됨.

ㅇㅇ 이렇게 인간과 몬스터는 모두 움직이니까 움직이는걸 상속받고, 

좀비는 몬스터를 상속 받고, 뱀파이어도 몬스터를 상속받았음.

이제 생각해보니 인간이 한 종류만 있는게 아니고, 플레이어도 있고, 그냥 AI가 움직이는 NPC도 있는거임.

간단하게 추가해서, 인간을 상속받는 플레이어, NPC 클래스를 만들면 되는거임.

그런데 여기서 디자이너(기획자)가 우리 너무 움직이는 몬스터만 있는데, 거대거미라던지, 

아님 미믹같은 몬스터를 추가해볼까? 라고 하는거임.

??? 이게 무슨소리 ??? 이미 몬스터라는 객체는 움직이는 전제하에 설계된 클래스인데,

움직이지 않는 몬스터를 넣자고? 

그럼 뭐 아직 까지는 OK 하고 넘어갈수 있어. 왜냐면, 움직임 클래스에서 그 경우에 조건문을 걸고

안움직이게 하면 설계상으론 꺼림직해도, 그냥 별일 없이 넘어갈수 있으니까.

이제 얼추 프로토타입도 완성이 되었고, 게임을 돌려보니 재밌는것이 개발을 진행해도 무리가 없겠다 싶어서

프로그래머와 아티스트, 디자이너 모두가 열심히 작업을 했어.

그리고 이제 알파를 지나 게임을 좀더 확장 하고자 하는 상태에 도달했다고 보자.

NPC 중에 아군을 힐해주는 사제, 탱킹해주는 성기사 등등이 추가 되었고 뭐 기타등등 여러가지가 생겼어.

그래서 이런식으로 클래스 상속이 정리 되어 있음.

기존 알파 버젼 까지는 이런식으로 게임을 구현했고, 

이제 회의에서 추가적인 기획을 구상중인 단계인거임.

팀원들 모두가 신나서, 아이디어를 쏟아내자 이런 이런 아이디어가 나왔어.

리치라던지, 늑대인간 이라던지 리치는 사제처럼 몬스터 입장에서 힐을 해주고,

늑대인간 아군인데, 인간이 아닌 늑대 모습으로 다닐수 있는거고

갑자기 클래스에서 빨간불이 생긴거임.

사제의 힐링이란 기능을 움직임으로 올린다면, 현재의 상속 체계로도

몬스터 중에 구현이 가능함.

늑대인간도 몬스터란 클래스를 움직임으로 올리고, 아래에 새로운

아군 클래스와 적군 클래스를 넣는다면 구현이 가능해진거지.

물론 이렇게 클래스를 바꾸면 프로그래머는 밤새서 작업을 해야하고,

혹시나 이름이 겹쳐버리면 예상하지 못한 버그가 튀어나올수도 있는게 이런 상태임.

아니면 다중상속을 통해 인간중에 아군 클래스를 추가로 상속받고,

 몬스터중에 아군 클래스를 받은 몬스터, 적군 클래스를 받은 몬스터 기타 등등이 되고,

힐링 기능도 새로운 클래스를 만든 후에 사제 클래스와 리치 클래스에 각각 다중상속을 해주는거지.

???

뭔가 많이 꼬이기 시작했다는걸 느낄수있는데, 상속의 가장 큰 단점이 바로 이거임.

상속을 많이 받거나, 복잡하게 받는 경우엔 클래스 UML을 그려가면서 확인해야할 정도로 복잡해지고,

또 예기치 못한 버그나, 추후에 기획이 바뀌었을때 수정하기 곤란하다는 단점이 있음.

어떤 디자인도 추가되고, 사라지고, 수정되다 보면은 처음에 생각했던 것과는 달라지는게 현실인거지;;

그래서 다시 돌아보는게 컴포지션의 개념임.

좀비라는 클래스 대신에, 좀비라는 오브젝트는,

움직임 컴포넌트를 가지고 있고,

좀비 기능 컴포넌트를 가지고 있으면 

좀비가 되는거지.

뱀파이어도 움직임을 가지고 있고, 뱀파이어 기능을 가지고 있으면 

뱀파이어 인거고, 

...

모든 상속 체계에서 말단에 속하는 결과물들의 구성요소들을 분해한후에

하나하나 조립하듯이, 추가해주면 결과물들이 튀어 나오는거임.

이게 기존에 있던 컴포지션 개념이고, 요즘 나오는 게임엔진들은 죄다 컴포넌트 베이스 게임엔진인 이유가 여기에 있는거임.

이제는 더 이상 기획하는데 상속을 고려할 필요가 없고, 그냥 구성 요소들을 조립하면 되니까.

그럼 이렇게 구현이 가능함.

훨씬 더 보기 편하고, 새로운 개념을 추가하기 편해진게 컴포지션으로 구현한 게임엔진임.

그리고 결론적으로 이렇게 구현을 해두면 클래스를 상속받아 만드는 경우엔 

추가로 코딩해서 컴파일을 새로 해야하는 경우가 대부분 이지만,

이런식으로 정렬되어있는 경우라면 저장되어있는 정보를 로드 하기만 해도

각각의 컴포넌트를 조합하는건 엔진이 알아서 할수 있게 되는거임.

갑자기 상속 이야기가 나와서 한마디 해봤음.

[hunnywind(hunnywind)]

개추

[부두술(badlow)]

저걸 컴포지션이라 부르는군

[부두술(badlow)]

또 또 심술부린다

[Puglet(puglet14)]

잘 알고 계시네요. 이런식으로 작업하는게 유니티에서 지향하는 객체지향 방식입니다. 한 번 컴포넌트들을 만들어 놓으면, 기획자가 프로그래밍을 몰라도 각각의 컴포넌트를 조합해서 새로운 캐릭터나 몬스터들을 만들어 낼 수 있는거죠.

[Puglet(puglet14)]

상속의 경우에는 업캐스팅 개념을 잘 모르신다면, 여러모로 자료구조로 다룰 때, 에러사항이 많이 발생하게 되니, 초보 프로그래머분들에게 상속을 사용하지 말라고 조언하는 것도 유효한 조언이라고도 생각되네요 :)

[123123(121.150)]

유니티나 언리얼이나 대부분의 상용엔진은 컴포지션으로 만드는 경우가 많음. 아니 요즘엔 대학생 프로젝트도 다 컴포지션으로 만드는 경우가 많은데, 생산성에서 월등히 올라가기 때문임.

[익명(106.240)]

이거 이해하면 유니티 만지기 존나쉬워짐 나는 이걸 학교에서 제대로 안배워서 이해하기힘들었었음

[Puglet(puglet14)]

그렇지만, 초보분들의 경우, upcasting/virtual/abstract 개념을 제대로 이해하지 못해서 오히려 낙오되는 경우도 종종 봐와서 여력이 안되는데 좋다고 억지로 사용하실 필요는 없으니, 입문자 분들은 자기 역량껏 판단하시면 좋을꺼같네요.

[익명(106.240)]

함께보면 좋은 참고문서 : 디자인패턴,컴포지트패턴,스트래티지패턴

[부두술(badlow)]

댓글 언제 지웠데 ㅂㄷㅂㄷ

[익명(121.135)]

와 이거 항상 햇갈렸는데 고맙습니다

[익명(121.135)]

제발 글삭하지 말아줘 두고두고 봐야할거 같음

[whatugonnado(sibal214)]

이거 물어보는애들 이 링크 줘야겠다 이제 ㅋㅋ

[_(ilyich762)]

컴포난트 컴포지샨

[익명(27.35)]

유니티는 c#이니 Action을 쓰면 편해요. Action은 컴포지션보다 좀더 세분화되서 메서드 단위로 모아줄 수 있기 때문에 대리자 없이 메서드를 호출할 수 있는 겁니다. 물론 이러면 구조가 기존과 많이 달라지는데, 유닛이면 유닛, 건물이면 건물에서 사용되는 메서드를 다 따로 사전에 모아놓고 유닛이 생성될 때에 기본적인 메서드를 사전에서 지정된 번호로 불러와서 받는 방식이에요.

[익명(27.35)]

예를 들어 인간은 마우스 클릭하면 안녕하고 인사하지만 노움은 클릭하면 도망간다고 해보죠. 양쪽다 Action clicked로 설정해두면 되요. 그리고 인간에게는 안녕 메서드를 clicked에 넣어주고 노움은 도망 메서드를 clicked에 넣어주면 구현이 되요. 유니티는 컴포넌트마다 이름이 다 다르게 되어있어서 안녕 메서드와 도망 메서드를 하드 코딩에서 하나로 불러오기 힘든데, Action을 써주면 그냥 그럴 고민 없이 쉽습니ㅏㄷ.

[익명(27.35)]

근데 Action을 박아주는건 하나 조심해야 하는게, 어디까지나 그 메서드는 넣어주는 클래스의 메서드라는 사실입니다. 즉, 빌려주는 것도 아니고 정말 원래 클래스의 메서드를 호출하는 것이기 때문에 유니티에서처럼 transform.posion = new Vector(x,y,z)과 같이 넣어주면 원래 사전 클래스의 위치가 변환되요. 이건 조심하셔야 합니다. 그리고 메서드를 따로 인스턴스해주는게 아니라 원래 있던걸 호출만 해주는 것이기 때문에 멀티 스레드에서도 쥐약이죠.

[地鬼(dczlatan)]

달다 달아

[地鬼(dczlatan)]

근데 컴포지션 얘기 듣고 있으니 인터페이스랑 비슷한 느낌인듯. IMove, IZombie 이런...