¿A quién debería pertenecer un método?

Question

Estoy tratando de diseñar un juego simple --- Pong, Arkanoid --- usando estrictamente "OO apropiado", lo que sea que eso signifique.

Así, mediante el diseño hasta morir, estoy tratando de llegar a un punto en el que voy a saber qué hacer o no hacer la próxima vez ...

Quién debe manipular, por ejemplo, colissions? ¿Y el marcador?

Mi primera idea fue darle un par de trabajos a la pelota, pero eso comenzó a expandirse exponencialmente en un objeto divino: la pelota sabía dónde estaba, con quién se estrelló y se reportó a los objetos de marcador.

Y eso es demasiado para la pelota pobre.

Answer 1

regla de oro:

• si un objeto posee lógicamente todo el estado involucrada, entonces es titular de los métodos que utilizan ese estado
• si un método requiere el estado de más de un objeto:
  • si un objeto contenedor posee todos los objetos utilizados por el método, entonces posee el método, también
  • de lo contrario se necesita un objeto de 'puente' para poseer el método de utilidad
  • a menos que haya un fuerte argumento a favor de un objeto a ser el 'controlador' para el método (no se puede pensar en un ejemplo de improviso, aunque)

en su caso, el 'tablero de juego' o " entorno de juego 'probablemente tenga una clase de' física de juegos '(o grupo de métodos) que posea los métodos de detección de colisiones (servicio/puente)

Answer 2

Realmente depende de su implementación, pero me imagino que tendría un objeto "de tablero de juego" para administrar el mantenimiento de puntaje, o tal vez un objeto objetivo en cada lado. En cuanto a las colisiones, creo que es posible que desee pasar eventos entre los objetos. Creo que cualquier objeto debería saber su ubicación sin embargo.

Answer 3

en la mayoría de los juegos tienes estáticos y actores. .. los actores se mueven y cada uno de ellos se da cuenta de forma independiente cuando colisionan con algo, ya que conocen su forma y sus extensiones

Answer 4

Un diseño bueno o malo se revela por lo bien que satisface los requisitos inesperados, por lo que sugiero mantenerlo un inventario de posibles "características del juego" útiles para informar sus reflexiones de diseño. Ya que estás haciendo esto como un proyecto de aprendizaje, puedes permitirte el lujo de volverse loco.

Arkanoid es una muy buena opción para esto, ofrece tantas opciones. Haz que diferentes ladrillos obtengan diferentes cantidades de puntos. Haz que algunos ladrillos cambien el puntaje de otros ladrillos cuando los golpees. Hacer algunos ladrillos requiere múltiples golpes. Da superpoderes a la pelota, paleta o ladrillos. Varíe estos poderes: uno de ellos hace que la bola sea controlable por teclado, otra la hace transparente, otra invierte la "gravedad", y así sucesivamente. Haz que los ladrillos caigan objetos.

El objetivo es que cuando se realiza un cambio de este tipo, afecte la menor cantidad posible de clases y métodos. Obtenga una idea de cómo debe cambiar su diseño para ajustarse a este criterio.

Use un IDE que tenga un menú Refactoring, en particular método de movimiento refactorización.(Si no lo ha hecho, lea el libro Refactoring). Experimente colocando sus diversos métodos aquí y allá. Observe lo que se vuelve difícil de cambiar cuando el método se coloca "mal", y lo que se vuelve más fácil cuando lo coloca en otro lugar. Los métodos se colocan justo cuando los objetos se ocupan de su propio estado; puede "decirle" a un objeto que haga algo, en lugar de "preguntarle" sobre su estado y luego tomar decisiones en función de sus respuestas.

Supongamos que en su diseño cada sprite es una instancia de objeto. (Puedes elegir otras estrategias.) Generalmente, el movimiento altera el estado de un sprite, por lo que el método que describe el movimiento para un tipo particular de sprite probablemente pertenece a la clase de ese sprite.

La detección de colisiones es una parte sensible del código, ya que implica la posibilidad de verificar todos los pares posibles de sprites. Usted querrá distinguir marcando para colisiones y informando objetos de colisiones. Por ejemplo, tu bola de objeto necesita modificar su movimiento al colisionar con la pala. Pero el algoritmo para detectar colisiones en general no pertenecerá a la clase de bola, ya que otros pares de objetos pueden colisionar con las consecuencias que importan para el juego.

Y así sucesivamente ...

Answer 5

Tenga en cuenta que también pueden existir objetos para los elementos lógicos de un problema dado (no sólo reales elementos, como pelotas y tableros).

Por lo tanto, para la detección de colisiones, puede tener una clase CollidingElement que maneje los estados de posición y forma. Este objeto puede ser incrustado por la composición en cualquier objeto que debe colisionar en el juego y delegar cualquier llamada al método necesario.