다중 상속이 엔티티 시스템의 모든 문제를 해결하지 않습니까?

질문은 꽤 자기 설명 적입니다. 다중 상속이 엔티티 시스템이 해결하는 모든 문제를 해결하지 않습니까?

방금 "다중 상속 (multiple inheritance)"이라는 용어를 기억했는데, 그것은 고전 상속이 부과 한 많은 팽팽한 문제를 해결하는 것으로 보입니다.

아니요, 다중 상속이 엔티티 시스템과 동일한 문제를 모두 해결하지는 못합니다. 엔티티 시스템과 다중 상속은 매우 다른 두 가지입니다. 다중 상속 유무에 관계없이 엔티티 시스템을 구축 할 수 있으며 마찬가지로 엔티티 시스템을 구축하지 않고도 다중 상속을 활용할 수 있습니다.

전통적으로 구성 요소 중심 엔티티 시스템은 구성을 목표로 어떤 형태로든 상속을 멀리 하려는 바람에 의해 개발되었습니다 . 프로그래머 나 SE 자체 에 대한이 논문의 다른 곳에 충분한 문헌과 토론이 있으며, 왜 작곡을 선호 하는지 에 대한 더 큰 문제는 게임 개발에서 주제를 벗어난 것입니다. 요컨대, 그것은 변경 가능성과 유지 보수성을 향상시키는 경향이있는 접근법입니다.

조쉬의 대답은 훌륭하지만 추가하고 싶습니다.

Entity / Component의 가장 멋진 기능 중 하나는 게임의 모든 "물건"을 만들고 관리하는 데이터 중심 방식입니다. 내가 본 것에서 멋진 구성 요소 유형 라이브러리가 만들어지면 최소한의 코드 수정만으로 무엇이든 만들 수 있습니다. (참고 : minimal! = 0 )

동작 측면에서 게임을 정의하고 런타임에 스크립트 나 데이터베이스 등에서로드하여 초기화하는 동안 이러한 동작을 즉석에서 수정할 수있는 능력을 부여함으로써 새로운 가능성의 세계를 열 수 있습니다. 그림자가 예상 한 곳에 도달하지 않는 이유를 알고 싶습니까? 조명에 카메라 / POV 구성 요소를 추가하십시오.

엔터티 / 구성 요소를 사용하면 블록을 만든 한 원하는 것을 만들 수 있습니다.

또한 다중 상속은 단일 상속과 동일한 문제를 일으 킵니다. 계층 구조에서 특성이나 동작을 추가하면 전파됩니다. 심층적 인 계층 구조를 만드는 한 불필요한 무게를가하거나 코드를 복제하거나 충돌을 해결하는 상황에 처하게됩니다. 게임을 데이터로 상상할 때 대부분을 피할 수 있습니다.

나는 지난 몇 주 동안 이것을 가지고 놀기 시작했지만, 일이 얼마나 간단한 지 감명 받았습니다. 은색 총알이 아닙니다. 구성 요소에 람다를 연결하는 것이 문제를 해결하는 가장 깨끗하고 편리한 방법 인 몇 가지 사례를 거쳤습니다.

약간 관련된 참고 사항 : 데이터 중심 응용 프로그램 (웹 사이트 등)의 크고 지루한 유지 관리 생성기 중 하나는 계층 적 개체를 관계형 데이터베이스에 매핑합니다. 우리는 주위에 많은 멋진 솔루션을 가지고 있지만 궁극적으로 계층 구조를 평평하게하기 위해 설계된 모든 핵입니다. 응용 프로그램의 목적에 부합하도록 모델을 구축하는 대신 효과적인 계층 구조와 논리적 관계 표현 사이에서 타협 할 수 있습니다. 엔터티 / 구성 요소 시스템으로 내 응용 프로그램 중 하나에서 꽤 큰 계층 구조를 재구성한다는 아이디어를 가지고 놀았습니다. 계층을 버리고 나머지 구현의 데이터베이스를 골드 표준으로 만들면 유망합니다.

성능 문제를 해결할 수있는 동적 코드 생성 / 코드 캐싱과 같은 기능을 통합 할 때 OOP의 재사용 가능한 코드 목표를 훨씬 더 나은 방식으로 실현할 수있는 빠르고 유연하며 논리적 인 아키텍처로 발전 할 수 있습니다.