[💬] 유니티의 단점은 상속에 인색하다는점임

[익명(175.223)]

유니티는 참좋은 엔진이지만 유니티에서 제공하는 컴포넌트 대부분과 게임오브젝트는 상속을 내릴수없는데 정말 별로인거 같음

예를들어 내나름의 용도로 유니티 Button 컴포넌트를 상속받아 ToggleButton 이런식으로 만들고 게임오브젝트에 Add해서 쓰고싶음

근데 유니티로 이런걸 하려면 독자적인 ToggleButton 컴포넌트를 만들고 거기서 Button을 Get해서 동작을 하고 게임오브젝트에 Button, ToggleButton 을 둘다 Add시켜야함

토글버튼이면 토글버튼, 버튼이면 버튼이지. 둘다 가지고있다는게
프로그램 논리상으로 굉장히 이상함

CharacterContlloer도 마찬가지임. 그냥 상속내려서 PlayerCharactetController, MonsterCharacterController 이런식으로 나누고싶은데 이런게 안됨

c++는 상속을 막는키워드가 없는데 c#은그게 되서 참불편함
진짜 오버라이드 하면 안되는 함수들만 final 붙이고 상속풀어줘도 될텐데..

[익명(122.211)]

컴퍼넌트 지향이니까 그런거 아닌가 싶었는데... 버튼 컴퍼넌트, 이미지 컴퍼넌트 따로 있듯이, 토글속성 컴퍼넌트를 붙인다는 식으로 접근하면 어떨까

[익명(122.211)]

토글속성 컴퍼넌트는 그게 UI버튼일 때도 있고, 필드상에 설치된 지뢰나 스위치 같은 거일 수도 있고 그런 식으로 하면 유니티가 의도한 접근이 될 거 같음

[익명(175.223)]

윗분은 에픽게임즈는 심심해서 엑터 상속받아 캐릭터랑 폰만들라고 한줄아시나봄

[익명(175.223)]

언리얼도 ecs는 유지하면서 블루프린트 조차도 네이티브 클래스 상속받아서 만들수있도록 하는판인데 뭔ㅋㅋㅋ

[익명(175.223)]

까놓고말해 상속이 무조건 답인건 아니지만 필요할때 사용하도록 풀어줘야지. 유니티는 오버라이드 하면 엔진에 사이드이팩트 발생할 가능성이 있어서 막아논거지 유니티 윗대가리가 프로그래머인게 뭔상관이냐? 게임엔진을 프로그래머가 만들지 그럼 누가만들어

[익명(14.50)]

? 제생각엔 윗분이 더 틀딱같아요. 대세 따르라면서 뭐 미천하다느니 뭐냐느니 ㅋㅋㅋㅋㅋ... 객체지향에서 상속이 코드 재사용에 이점이 있다는 좋은 점이 있어서 상속이 좋다는 생각을 할 수도 있는거지... 가능하다면 열어둬야 프로그래머가 설계에서 선택할 여지가 많아지고 좋은거 아님? ECS도 결국은 상속할때 필요 없는 멤버 생겨서 쓴다 등 나름의 이유가 있어서 쓰는건데 반대로 ECS 적용했을 때 저분 말대로 프로그램 논리적으로 어색하게 느껴지거나 코드에 일관성 넣어서 확장하기 쉽게 만들고 생산성을 도모할 수도 있는거죠 ㅋㅋ

[이 댓글은 게시물 작성자가 삭제하였습니다.]

이 댓글은 게시물 작성자가 삭제하였습니다.

[익명(175.223)]

cpp도 final인데요ㅋㅋ

[ㅇㄷㄴ(223.38)]

졷같으면 소스 사라.