¿La herencia múltiple no resuelve todos los problemas que hacen los sistemas de entidades?

La pregunta se explica por sí misma: ¿la herencia múltiple no resuelve todos los problemas que los sistemas de entidades también resuelven?

Acabo de recordar un término llamado "herencia múltiple", y eso parece resolver muchos problemas de hinchazón que la herencia clásica impuso.

— jcora
fuente

La herencia múltiple es similar a los sistemas de entidades, pero no es lo mismo. Por ejemplo, varias entidades de herencia no pueden tener componentes agregados y eliminados en tiempo de ejecución. No todos los idiomas admiten herencia múltiple tampoco. También podría considerar que la composición está en la misma categoría frente a la entidad / componentes.

— MichaelHouse

Si sus clases ya son tan ordenadas que puede heredarlas sin problemas de la forma que desee, es posible que ya sean componentes. Los componentes también permiten la composición / agregación en tiempo de ejecución

Bueno, es más complejo y menos propenso a errores, entonces ¿por qué preferirlo?

— API-Beast

MI tampoco aborda realmente los problemas de "hinchazón", ya que heredar un exceso de interfaz de una clase o clases primarias es más un síntoma de un mal uso de un mecanismo de herencia en lugar de una herencia simple o múltiple. También se puede lograr la misma "hinchazón" en un enfoque orientado a la composición de un problema.

@ MrBeast ¿te refieres a más complejo / más propenso a errores, menos complejo / propenso a errores, o "¿por qué no lo prefieres?"

— 3Dave

Respuestas:

No, la herencia múltiple no resuelve los mismos problemas que los sistemas de entidades: los sistemas de entidades y la herencia múltiple son dos cosas muy diferentes. Puede construir un sistema de entidad con o sin herencia múltiple y, de manera similar, puede utilizar la herencia múltiple sin construir un sistema de entidad.

Tradicionalmente, los sistemas de entidades centrados en componentes se desarrollan debido a un deseo de alejarse de la herencia pesada en cualquier forma, con el objetivo de la composición . Hay suficiente literatura y discusión en otros lugares sobre este adagio, por ejemplo, sobre los programadores SE o SO , y la cuestión más amplia de por qué preferir la composición es algo fuera de tema para el desarrollo del juego. En resumen, sin embargo, es un enfoque que tiende a prestarse a una mejor mutabilidad y mantenibilidad.

— Comunidad
fuente

La respuesta de Josh es asombrosa, pero me gustaría agregar:

Una de las mejores características de Entity / Component es la forma basada en datos en la que cada "cosa" en su juego es creada y administrada. Por lo que he visto, una vez que haya creado una buena biblioteca de tipos de componentes y sistemas, puede construir casi cualquier cosa con mínimas modificaciones de código. (Nota: mínimo! = 0 )

Al definir tu juego en términos de comportamiento y al darte la posibilidad de modificar esos comportamientos sobre la marcha, en tiempo de ejecución, durante la inicialización cargándolos desde un script o base de datos, etc., abres un mundo entero de nuevas posibilidades. ¿Quieres ver por qué tus sombras no aterrizan donde esperas? Agregue un componente de cámara / POV a su luz.

Entidad / componente te permite construir lo que quieras, siempre que hayas creado los bloques.

Además, la herencia múltiple causa el mismo problema que la herencia única. Cuando agrega un atributo o comportamiento en la jerarquía, se propaga. Mientras esté haciendo jerarquías profundas, se encontrará con situaciones en las que tendrá un peso innecesario, duplicará código o resolverá conflictos. La mayor parte de eso se puede evitar cuando imaginas tu juego como datos.

Acabo de empezar a jugar con esto en las últimas semanas, pero estoy impresionado de lo simples que se han vuelto las cosas. No es una bala de plata: me he encontrado con algunos casos en los que conectar una lambda a un componente era la forma más limpia y conveniente de resolver un problema, pero es un patrón bastante bueno, si se puede llamar así.

En una nota ligeramente relacionada: uno de los grandes y aburridos generadores de mantenimiento en aplicaciones centradas en datos (sitios web, etc.) está mapeando objetos jerárquicos en bases de datos relacionales. Tenemos muchas soluciones ingeniosas, pero en última instancia, todas son hacks diseñados para aplanar las jerarquías. En lugar de construir su modelo de modo que sirva para el propósito de la aplicación, termina comprometiéndose entre una jerarquía efectiva y una representación relacional lógica. He estado jugando con la idea de reconstruir una jerarquía bastante grande en una de mis aplicaciones como un sistema de entidad / componente, deshacerse de la jerarquía y hacer que la base de datos sea el Estándar de Oro para el resto de la implementación, y es prometedor.

Cuando integra capacidades como la generación dinámica de código / almacenamiento en caché de código que puede abordar problemas de rendimiento, termina con una arquitectura rápida, flexible y lógica que podría alcanzar el objetivo de código reutilizable de OOP de una manera mucho, mucho mejor.

— 3Dave
fuente