Наследование против композиции


16

Я зарабатываю деньги на C # Вообще на этом языке мне нравится отделять все до небес, используя интерфейсы. Это хорошо послужило мне в корпоративном коде, но при написании игр на C # я обнаружил, что склоняюсь к наследованию из-за возможности определить некоторые поведения по умолчанию для базовых классов. Я чувствую себя грязно, когда делаю это, как будто я не подчиняюсь некоему богу архитектуры, который однажды сказал: «одобряй композицию, а не наследование». Я знаю, что это не черно-белый, но я также чувствую, что я мог бы использовать интерфейсы с немного большим количеством работы и достичь примерно того же самого.

Что делают другие люди? Является ли наследование правильным подходом для игр или я должен рефакторинг в некоторых интерфейсах?


1
Интерфейсы также не являются композицией, поэтому не ясно, о чем вы спрашиваете.

Я просто хочу отметить, что, поскольку вы работаете с C #, вам будет трудно, если вы решите использовать наследование, поскольку C # не поддерживает истинное множественное наследование. Использование метода с несколькими интерфейсами хорошо, пока вы не войдете в диапазон 4-5 интерфейсов и не будете вынуждены вырезать / вставлять более 25 строк кода между каждым классом, имеющим одинаковую реализацию. Есть несколько обходных путей, но они такие же уродливые, поскольку язык не обеспечивает прямой поддержки.
NtscCobalt

Ответы:


23

Наследование в играх на самом деле является одной из худших вещей, которые вы можете сделать, особенно в отношении сущностей. Прочитайте это почему. Композиция над наследованием проделывает долгий путь с играми. Что касается других областей вашего двигателя, это не имеет большого значения. Скажем, например, что вы делаете вызов какой-либо внешней сетевой службе, тогда вы можете наследовать один универсальный тип службы, например. HTTPService и SocketService - во многом как в корпоративных приложениях, к которым вы привыкли.

Если ваша игра не очень просто, вы будете хотеть использовать сущности (CBE) архитектуру на основе компонентов. Общая идея заключается в том, что для сущностей причина, по которой они так часто составляются, а не наследуются, заключается в том, что вы не можете знать до времени выполнения, какие возможности у данной сущности будут, Например, возьмите корабль игрока в космическом шутере. Вы не знаете до определенного момента во время игры, какое оружие, броня, системы (т.е. компоненты), которые игрок собирается подобрать, купить, продать, потерять, уничтожить и т. Д. Таким образом, единственный реалистичный способ смоделировать это через композицию объектов. Плюсом в этом сценарии является то, что вы также можете иметь полностью настраиваемых врагов, построенных таким же образом, а не врагов, которые всегда одинаковы каждый раз, когда вы видите этот тип врага. Таким образом, с CBE вы можете увидеть марсианский фрахтовщик и подумать: «Ах, у него только крошечные лазеры, я его снесу», и обычно это было бы правдой, но когда вы попадаете в зону действия внезапно, вы понимаете, что у него большая задница. червоточина Сюрприз Сюрприз!

Компонентация удаляет неявную связь логики, и это ХОРОШО.


Спасибо за совет, приятель :) Приятно знать, что я не слышал голоса!
Питер Шорт

1
+1 Спасибо за статью, я давно собирался сделать это в своей игре
Джон Макдональд

3
Следует отметить, что из-за высокой взаимозависимости игровых объектов наследование часто усложняет ситуацию и делает обслуживание и расширение трудоемкой задачей. Компонентные системы хорошо справляются с этой проблемой, а другая дополнительная выгода - это то, что указано в ответе выше;)
Джеймс

Также следует отметить, что «но когда вы попадаете в зону действия внезапно, вы понимаете, что у него есть червоточина с большой задницей. Сюрприз-сюрприз!» плохой игровой дизайн: D
Джонатан Коннелл

1
Сюрпризы - это весело, но сюрпризы, которые означают, что вы умрете без предупреждения, как низкоуровневый корабль, который может вас ОХКО, просто разочаровывают;) Конечно, это может быть не тем, что вы имели в виду в своем ответе. Кроме того, в игре есть гораздо больше, чем просто игровой дизайн.
Джонатан Коннелл

3

Для тех, кто говорит по-немецки интересная книга: 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

Для себя я выбираю свою архитектуру в зависимости от размера проекта и возможности расширения или повторного использования кода. Зачем тратить часы и часы на архитектуру микропроекта, где нет шансов снова использовать код? В то же время вы можете закончить проект.

Композиция vs Компоненты Компоненты - это крутые и причудливые вещи, но в большинстве проектов / архитектур композиция тоже подойдет (без накладных расходов на основе компонентов). Это зависит от того, что ваша компонентная система может обеспечить, что композиция не может.


Например, возьмите корабль игрока в космическом шутере. Вы не знаете до определенного момента во время игры, какое оружие, броня, системы (т.е. компоненты), которые игрок собирается подобрать, купить, продать, потерять, уничтожить и т. Д. Таким образом, единственный реалистичный способ смоделировать это через композицию объектов.

все это было возможно и без компонентов давным-давно


-1, компоненты являются формой композиции.

ну, форма, но не то же самое, поскольку они предоставляют разные функции. (Так что я не понимаю ваш комментарий и -1)
idefix

1
Когда вы говорите «композиция против компонентов», неясно, что вы сравниваете, так как компоненты являются композицией. Вы имеете в виду динамические компоненты против статических компонентов? Любой из этих типов по сравнению с составом типов не связан ни семейно, ни структурно? Что такое «накладные расходы на основе компонентов»? В статических компонентных системах (и многих динамических) издержки почти равны нулю.

Хм, интересные моменты. Вы не против немного более детального обсуждения? Если нет, я бы хотел отправить вам свой почтовый адрес на другой платформе.
idefix
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.