Herencia vs Composición


16

Gano mi dinero en C # Generalmente en ese lenguaje me gusta desacoplar todo a los cielos usando interfaces. Esto me ha servido bien en el código de la empresa, pero al escribir juegos en C # me encuentro con tendencia a la herencia debido a la capacidad de definir algunos comportamientos predeterminados para las clases base. Sin embargo, me siento sucio haciendo esto, como si estuviera desobedeciendo a un dios de la arquitectura que una vez dijo "favorecer la composición sobre la herencia". Sé que no es en blanco y negro, pero también siento que podría usar interfaces con un poco más de trabajo y lograr aproximadamente lo mismo.

¿Qué hacen otras personas? ¿Es la herencia el enfoque correcto para los juegos o debería refactorizar en algunas interfaces?


1
Las interfaces tampoco son composición, por lo que no está claro lo que está preguntando.

Solo quiero mencionar que dado que está trabajando con C #, le resultaría difícil si opta por usar la herencia, ya que C # no admite la herencia múltiple verdadera. El uso del método de interfaz múltiple está bien hasta que entre en el rango de interfaz 4-5 y tenga que cortar / pegar más de 25 líneas de código entre cada clase que comparte la misma implementación. Hay algunas rondas de trabajo pero son igual de feas ya que el lenguaje no proporciona soporte directo.
NtscCobalt

Respuestas:


23

La herencia en los juegos es en realidad una de las peores cosas que puedes hacer, en particular con respecto a las entidades. Lea esto por qué. La composición sobre la herencia te lleva muy lejos con los juegos. En cuanto a otras áreas de su motor, realmente no importa. Digamos, por ejemplo, que está llamando a algún tipo de servicio de red externo, luego puede heredar un servicio de tipo genérico, por ejemplo. HTTPService y SocketService, tanto como en las aplicaciones empresariales a las que está acostumbrado.

A menos que su juego es muy simple, que se desea utilizar una entidad arquitectura basada en componentes (CBE). La idea general es que con las entidades, la razón por la que se componen tan comúnmente en lugar de heredarse es porque no se puede saber hasta el tiempo de ejecución qué capacidades tendrá una entidad determinada. Por ejemplo, toma la nave del jugador en un tirador espacial. No sabes hasta algún momento durante el juego, qué armas, armaduras, sistemas (es decir, componentes) que el jugador va a recoger, comprar, vender, perder, haber destruido, etc. Así que la única forma realista de modelar esto es a través de la composición de objetos. El lado positivo de este escenario es que también puedes tener enemigos totalmente personalizables, construidos de la misma manera, en lugar de enemigos que siempre son exactamente iguales cada vez que ves ese tipo de enemigo. Entonces, con CBE, es posible que vea un Carguero marciano y piense: "Ah, solo tiene láseres pequeños, lo desmontaré", y generalmente eso sería cierto, pero cuando se pone al alcance de repente, se da cuenta de que tiene un gran culo pistola de agujero de gusano. ¡Sorpresa sorpresa!

La componente es eliminar el acoplamiento implícito de la lógica, y eso es BUENO.


Gracias por el consejo amigo :) ¡Es bueno saber que no estaba escuchando voces!
Peter Short

1
+1 Gracias por el artículo, he tenido la intención de hacer esto en mi juego desde hace bastante tiempo
John McDonald

3
Cabe señalar que, debido a la alta interdependencia de las entidades del juego, la herencia a menudo complica las cosas y hace que la mantenibilidad y la extensión sean una tarea engorrosa. Los sistemas de componentes abordan este problema muy bien y el otro beneficio adicional es el que se enumera en la respuesta anterior;)
James

También debe tenerse en cuenta que el "pero cuando entras en rango de repente te das cuenta de que tiene un arma de agujero de gusano de gran culo. ¡Sorpresa sorpresa!" es un mal diseño del juego: D
Jonathan Connell

1
Las sorpresas son divertidas, pero las sorpresas que significan que mueres sin previo aviso, como un barco de bajo nivel que puede OHKO, son frustrantes;) Por supuesto, esto puede no ser lo que quisiste decir en tu respuesta. Además, hay mucho más en un juego que solo el diseño del juego.
Jonathan Connell

3

Para quienes hablan alemán, un libro interesante: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Una mirada más cercana sobre cuándo y por qué usar qué arquitectura se puede encontrar aquí: /programming/1901251/component-based-game-engine-design

Por mí mismo, decido mi arquitectura dependiendo del tamaño del proyecto y la posibilidad de extender o reutilizar el código. ¿Por qué invertir horas y horas en la arquitectura de un microproyecto donde no hay posibilidad de que vuelva a usar el código? Al mismo tiempo, puede finalizar el proyecto.

Composición vs Componentes Los componentes son cosas geniales, pero en la mayoría de los proyectos / arquitecturas, la composición también lo hará (sin gastos generales basados ​​en componentes). Depende de lo que su sistema de componentes pueda proporcionar que la composición no pueda.


Por ejemplo, toma la nave del jugador en un tirador espacial. No sabes hasta algún momento durante el juego, qué armas, armaduras, sistemas (es decir, componentes) que el jugador va a recoger, comprar, vender, perder, haber destruido, etc. Así que la única forma realista de modelar esto es a través de la composición de objetos.

todo eso fue posible sin componentes hace mucho tiempo también


-1, los componentes son una forma de composición.

bueno, una forma de, pero no la misma, ya que proporcionan características diferentes. (Así que no entiendo tu comentario y -1)
idefix

1
Cuando dices "composición frente a componentes" no está claro qué estás comparando ya que los componentes son composición. ¿Te refieres a componentes dinámicos versus componentes estáticos? ¿Alguno de esos versus composición de tipos relacionados ni familiarmente ni estructuralmente? ¿Qué es la "sobrecarga basada en componentes"? En sistemas de componentes estáticos (y muchos dinámicos) la sobrecarga es casi cero.

Hm, puntos interesantes. ¿Te importa un poco más de discusión detallada? Si no, me gustaría enviarle mi dirección de correo en otra plataforma.
idefix
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.