L'ereditarietà multipla non risolve tutti i problemi che i sistemi di entità fanno?

La domanda è piuttosto autoesplicativa: l'ereditarietà multipla non risolve tutti i problemi che risolvono anche i sistemi di entità?

Ho appena ricordato un termine chiamato "eredità multipla", che sembra risolvere molti problemi di gonfiore che l'eredità classica ha imposto.

— jcora
fonte

L'ereditarietà multipla è simile ai sistemi di entità, ma non è la stessa. Ad esempio, a più entità ereditarie non è possibile aggiungere e rimuovere componenti in fase di esecuzione. Non tutte le lingue supportano l'ereditarietà multipla. Puoi anche considerare che la composizione è nella stessa categoria rispetto a entità / componenti.

— MichaelHouse

Se le tue classi sono già così ordinate da poterle ereditare senza problemi insieme nel modo che preferisci, potrebbero essere già componenti. I componenti consentono anche la composizione / aggregazione in fase di esecuzione

Bene, è più complesso e meno soggetto a errori, quindi perché preferirlo?

— API-Beast,

Anche l'MI non affronta realmente i problemi di "gonfiore", poiché ereditare un eccesso di interfaccia da una o più classi genitore è più un sintomo dell'uso scarso di un meccanismo di ereditarietà piuttosto che di eredità singola contro multipla. Lo stesso "gonfiore" può essere raggiunto anche in un approccio orientato alla composizione di un problema.

@MrBeast intendi più complesso / più soggetto a errori, meno complesso / soggetto a errori o "perché non preferirlo?"

— 3Daveva il

Risposte:

No, l'ereditarietà multipla non risolve tutti gli stessi problemi dei sistemi di entità: i sistemi di entità e l'ereditarietà multipla sono due cose molto diverse. È possibile creare un sistema di entità con o senza eredità multipla e allo stesso modo è possibile utilizzare l'eredità multipla senza creare un sistema di entità.

Tradizionalmente, i sistemi di entità incentrati sui componenti sono sviluppati a causa del desiderio di allontanarsi dalla pesante eredità in qualsiasi forma, mirando invece alla composizione . C'è abbastanza letteratura e discussione altrove su questo adagio, ad esempio sui programmatori SE o SO stessi , ed è la questione più ampia del perché preferire la composizione è una sorta di off-topic per lo sviluppo del gioco. In breve, tuttavia, è un approccio che tende a prestarsi a una migliore mutabilità e manutenibilità.

— Comunità
fonte

La risposta di Josh è fantastica, ma vorrei aggiungere:

Una delle caratteristiche più interessanti di Entity / Component è il modo basato sui dati in cui ogni "cosa" nel tuo gioco viene creata e gestita. Da quello che ho visto, una volta creata una bella libreria di tipi di componenti e sistemi, puoi creare praticamente qualsiasi cosa con modifiche minime al codice. (Nota: minimo! = 0 )

Definendo il tuo gioco in termini di comportamento e dandoti la possibilità di modificare quei comportamenti al volo - in fase di esecuzione, durante l'inizializzazione caricandoli da uno script o da un database, ecc. - apri un intero mondo di nuove possibilità. Vuoi vedere perché le tue ombre non atterrano dove ti aspetteresti? Aggiungi un componente fotocamera / POV alla tua luce.

Entità / componente ti consente di creare tutto ciò che desideri, purché tu abbia creato i blocchi.

Inoltre, l'ereditarietà multipla causa lo stesso problema dell'ereditarietà singola. Quando aggiungi un attributo o un comportamento nella gerarchia, si propaga. Finché crei gerarchie profonde, ti imbatterai in situazioni in cui stai portando peso inutile, duplicando il codice o risolvendo conflitti. Gran parte di questo può essere evitato quando immagini il tuo gioco come dati.

Ho appena iniziato a giocare con questo nelle ultime settimane, ma sono impressionato da come sono diventate le cose semplici. Non è un proiettile d'argento - ho incontrato alcuni casi in cui collegare un lambda a un componente era il modo più pulito e più conveniente per risolvere un problema - ma è un modello abbastanza grande, se così puoi chiamarlo.

Su una nota leggermente correlata: uno dei generatori di manutenzione grandi e noiosi nelle applicazioni incentrate sui dati (siti Web, ecc.) È la mappatura di oggetti gerarchici in database relazionali. Abbiamo un sacco di soluzioni eleganti in giro, ma alla fine sono tutti hack progettati per appiattire le gerarchie. Invece di costruire il tuo modello in modo che funzioni allo scopo dell'applicazione, finisci per scendere a compromessi tra una gerarchia efficace e una rappresentazione relazionale logica. Ho avuto l'idea di ricostruire una gerarchia piuttosto grande in una delle mie app come un sistema di entità / componente - abbandonare la gerarchia e rendere il database lo standard di riferimento per il resto dell'implementazione - ed è promettente.

Quando si integrano funzionalità come la generazione dinamica del codice / memorizzazione nella cache del codice in grado di affrontare i problemi di prestazioni, si finisce con un'architettura logica, veloce e flessibile che potrebbe realizzare l'obiettivo di codice riutilizzabile di OOP in un modo molto, molto migliore.

— 3Dave
fonte