상속 대 구성

저는 C #으로 돈을 벌고 있습니다. 일반적으로 그 언어로 인터페이스를 사용하여 모든 것을 높은 하늘로 분리하고 싶습니다. 이것은 엔터프라이즈 코드에서 나에게 도움이되었지만 C #으로 게임을 작성할 때 기본 클래스의 기본 동작을 정의 할 수 있기 때문에 상속을 향한 경향이 있습니다. 한때 "상속보다 선호하는 구성"이라고 말한 건축 신에게 불순종하는 것처럼, 나는 이것을하는 것이 더럽다고 느낀다. 나는 흑백이 아니라는 것을 알고 있지만 조금 더 많은 작업으로 인터페이스를 사용하고 거의 같은 것을 달성 할 수 있다고 생각합니다.

다른 사람들은 무엇을합니까? 상속은 게임에 대한 올바른 접근법입니까, 아니면 일부 인터페이스에서 리팩터링해야합니까?

게임의 상속은 실제로 엔터티와 관련하여 할 수있는 최악의 일 중 하나입니다. 읽기 이 이유를 위해. 상속을 통한 구성은 게임과는 거리가 멀다. 엔진의 다른 영역은 실제로 중요하지 않습니다. 예를 들어 일종의 외부 네트워크 서비스를 호출한다고 가정하면 하나의 일반 유형 서비스를 상속 할 수 있습니다. HTTPService 및 SocketService-익숙한 엔터프라이즈 앱과 매우 유사합니다.

게임은 정말 간단하지 않는 한, 당신은 할 기능 구성 요소 기반 엔티티 (CBE) 아키텍처를 사용하고 싶습니다. 일반적인 아이디어는 엔터티를 사용하면 상속 되지 않고 일반적으로 구성되는 이유 는 주어진 엔터티가 어떤 기능을 수행하는지 런타임까지 알 수 없기 때문 입니다.. 예를 들어, 우주선을 우주 사수로 가져 가십시오. 게임 플레이 도중 어느 시점까지 플레이어가 어떤 무기, 갑옷, 시스템 (예 : 구성 요소)을 픽업, 구매, 판매, 패배, 파괴했는지 등을 알 수 없습니다. 따라서 이것을 모델링하는 유일한 현실적인 방법은 객체 구성을 통해. 이 시나리오의 장점은 적 유형을 볼 때마다 항상 동일한 적보다 동일한 방식으로 완전히 사용자 정의 가능한 적을 가질 수 있다는 것입니다. CBE를 사용하면 Martian Freighter를보고 "작은 레이저 만 가지고 있으면 내려 받게 될 것입니다"라고 생각할 수 있습니다. 보통은 사실이지만 범위 내에 들어가면 갑자기 큰 엉덩이를 가지고 있다는 것을 알게됩니다 웜홀 건. 놀람!

구성 요소 화는 암시적인 로직 커플 링을 제거하고 있으며 이는 GOOD입니다.

독일어로 흥미로운 책을 말하는 사람들을 위해 : http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

/programming/1901251/component-based-game-engine-design : 언제 어디서 왜 어떤 아키텍처를 사용해야하는지 자세히 살펴보십시오.

나는 스스로 프로젝트의 크기와 코드를 확장하거나 재사용 할 수있는 가능성에 따라 아키텍처를 결정한다. 코드를 다시 사용할 가능성이없는 마이크로 프로젝트의 아키텍처에 시간과 시간을 투자해야하는 이유는 무엇입니까? 동시에 프로젝트를 완료 할 수 있습니다.

컴포지션 및 컴포넌트 컴포지션은 멋진 기능이지만 대부분의 프로젝트 / 아키텍처에서 컴포지션은 컴포넌트 기반 오버 헤드 없이도 그 기능을 수행합니다. 구성 요소가 제공 할 수없는 구성 요소 시스템에 따라 다릅니다.

예를 들어, 우주선을 우주 사수로 가져 가십시오. 게임 플레이 도중 어느 시점까지 플레이어가 어떤 무기, 갑옷, 시스템 (예 : 구성 요소)을 픽업, 구매, 판매, 패배, 파괴했는지 등을 알 수 없습니다. 따라서 이것을 모델링하는 유일한 현실적인 방법은 객체 구성을 통해.

오래 전에 컴포넌트 없이도 가능했던 모든 것