Чи багаторазове успадкування не вирішує всіх проблем, які роблять сутні системи?

Питання досить самопояснюється: чи не багаторазове успадкування не вирішує всіх проблем, які також вирішують сутні системи?

Я просто згадав термін під назвою "багаторазове успадкування", і це, здається, вирішує багато проблем з набряком, які накладає класична спадщина.

Ні, багатократне успадкування не вирішує всіх тих самих проблем, що і сутні системи: сутні системи та багатократне успадкування - це дві дуже різні речі. Ви можете створити сутність системи з або без множинного успадкування, і аналогічно ви можете використовувати безліч успадковань, не будуючи систему сутності.

Традиційно системи, орієнтовані на компоненти, розробляються через бажання відійти від важкого успадкування в будь-якій формі, прагнучи замість цього складу . В інших місцях є достатня кількість літератури та дискусій щодо цієї приказки, наприклад, про програмістів SE або SO , і це питання більш важливо, чому віддавати перевагу композиції, є свого роду поза темою для розвитку ігор. Одним словом, однак, це підхід, який схильний піддаватися покращенню змінності та ремонту.

Відповідь Джоша приголомшлива, але я хотів би додати:

Однією з найкрутіших особливостей Entity / Component є спосіб, керований даними, завдяки якому кожна «річ» у вашій грі створюється та керується ними. З того, що я бачив, як тільки у вас створена приємна бібліотека типів компонентів і систем, ви можете будувати практично все, що стосується мінімальних модифікацій коду. (Примітка: мінімум! = 0 )

Визначаючи свою гру з точки зору поведінки та надаючи можливість змінювати поведінку під час руху - під час виконання, під час ініціалізації, завантажуючи їх із сценарію чи бази даних тощо - ви відкриваєте цілий світ нових можливостей. Хочете побачити, чому ваші тіні не приземляються там, де ви очікували? Додайте до світла компонент камери / POV.

Субстанція / компонент дозволяє будувати все, що завгодно, до тих пір, поки ви створили блоки.

Також багатократне успадкування спричиняє ту ж проблему, що і одиночне успадкування. Коли ви додаєте атрибут або поведінку в ієрархії, він поширюється. Поки ви створюєте глибоку ієрархію, ви будете стикатися з ситуаціями, коли ви несете зайву вагу, дублюєте код або вирішуєте конфлікти. Більшості цього можна уникнути, якщо уявити свою гру як дані.

Я тільки почав грати з цим за останні кілька тижнів, але мене вражає те, як прості речі стали. Це не срібна куля - я натрапив на кілька випадків, коли приєднання лямбда до компонента було найчистішим і найдоцільнішим способом вирішити проблему - але це досить чудова модель, якщо ви можете так назвати.

На дещо пов'язану з цим примітку: один із великих, нудних генераторів технічного обслуговування у додатках, орієнтованих на дані (веб-сайти тощо) - це відображення ієрархічних об'єктів у реляційні бази даних. У нас є безліч чудових рішень, але в кінцевому підсумку це всі хаки, покликані згладити ієрархії. Замість того, щоб будувати свою модель так, щоб вона відповідала меті програми, ви перебуваєте на компромісі між ефективною ієрархією та логічним реляційним поданням. Я бавився з ідеєю відновити досить велику ієрархію в одному з моїх додатків як система сутності / компонентів - скинути ієрархію та зробити базу даних Золотим стандартом для решти впровадження - і це перспективно.

Коли ви інтегруєте такі можливості, як динамічне генерування коду / кешування коду, які можуть вирішувати проблеми продуктивності, ви отримуєте швидку, гнучку логічну архітектуру, яка може просто реалізувати багатоцільову мету коду OOP багаторазово, набагато краще.