2011-09-01 17 views
7

Estoy tratando de escribir un juego de pelota simple, y hay varios turnos (es decir, vidas de pelota). La bola "muere" cuando pasa el borde inferior de la pantalla. Lo que tengo obras hasta ahora, pero no parece que sea la forma correcta de hacer las cosas:¿Se puede eliminar un objeto? ¿Cómo?

if (ball.getY() > bottomOfScreen) { 
    ball.die(); 
    remove(ball); 
} 

la matriz() método se desvanece básicamente el color de la pelota lentamente (dark_gray -> pausa (50) -> light_gray -> pausa (50)), pero en realidad no hace nada útil.

El remove(), obviamente, se deshace de la pelota de la pantalla, que es lo que quiero. Tiene sentido para mí que este remove() forme parte del método de morir de Ball(), en lugar de ser una llamada de método separada en el programa principal, pero no estoy seguro de cómo hacerlo.

¿Se puede eliminar un objeto? Y, si puede, ¿es el suicidio objetivo mejor que el asesinato objetal, desde un punto de vista filosófico/metodológico?

Gracias!

+0

Solo una sugerencia. El removedor primero debe asegurar que la bola muera, si no, entonces invoca el método die() y luego quítalo. –

Respuesta

4

El objeto puede eliminarse dado que tiene algún tipo de referencia al mecanismo de representación de vista. Su muestra no da suficiente información así que voy a ejemplificar una manera de hacerlo:

public class Ball { 
    private ViewRenderer view; 

    public void remove() { 
     view.remove(this); 
    } 
} 

Ni suicidio ni asesinato es mejor o peor. Depende de su diseño y requisitos.

En esta muestra, sin embargo, asesinato podría ser preferible ya que de esta manera el objeto Ballno necesita saber en qué contexto se está utilizando.

+1

Lo siento, tengo que rechazar esto. Funcionará, pero introduce una referencia circular: Ball tiene una referencia a ViewRenderer, y (presumiblemente) a ViewRenderer, una referencia a Ball. Tales cosas harán que las pruebas sean mucho más complicadas de lo que deben ser. – DJClayworth

+0

Gracias por explicar su razonamiento. Estás en lo correcto, aunque en un escenario más complejo (es decir, usando el patrón MVC/Observer), el objeto podría solicitar la eliminación, por ejemplo, a través del controlador de cambio regular. –

2

En un sentido de eliminación del objeto de la memoria: no, en Java que es manejado por el recolector de basura exclusivamente.

Lo que podría hacer es eliminar el objeto de las colecciones que lo contienen, pero esto requeriría que el objeto tenga acceso a esas colecciones (que en la mayoría de los casos no sería factible, ya que podría haber muchas colecciones).

Sugeriría el objeto que contiene (la pantalla en su caso) para sondear el estado del objeto contenido (la bola) y eliminarlo después de que esté realmente muerto.

3

Es posible crear un método en el cual la bola se quite, pero es algo malo de hacer. Para quitarse de la pantalla, la Bola debe tener una referencia a la pantalla. Esto crea una cadena circular de referencias (Ball tiene una referencia a la pantalla, la pantalla tiene una referencia a Ball) que va a hacer su diseño más complicado y su prueba mucho más complicada.

Suicidio está bien - la pantalla le dice a la pelota que muera, y la pelota muere. Pero se trata de eliminar una relación, no de morir. Lo que mantiene la relación es la pantalla, por lo que debería ser la cosa que elimina.

También recuerde que los dos no necesariamente tienen que suceder juntos. La pantalla podría querer mantener una bola muerta por alguna razón, y podría querer quitar una bola que no esté muerta. Incluso si eso no sucede en su aplicación ahora, permita la posibilidad.

1

Se supone que hay algún objeto (p.la Pantalla, o el ViewRenderer en el ejemplo de Johan) que contiene una referencia a la Bola, y eliminar esta referencia tiene que ser hecha por la Pantalla ("asesinato de objetos"). "Objeto suicida" equivale a Ball pasando un mensaje a la pantalla pidiendo ser "asesinado".

Dado que es la Bola la que sabe cuándo ha pasado el límite, tiene sentido para mí (sin conocer los detalles de su diseño) que la Bola inicie la eliminación. A continuación, la pantalla puede averiguar sobre este cambio por uno de varios medios:

  • La pantalla puede sondear la bola.
  • La bola puede contener una referencia directa hacia atrás a la pantalla, lo que crea una desafortunada dependencia circular.
  • La bola puede mantener una referencia a la pantalla a través de una interfaz BallObserver. Esta es una aplicación del observer pattern.

El primero es el más simple, y esto lo convierte en una buena opción si se adapta naturalmente a su mecanismo para pintar la pantalla. El tercero es más flexible en principio, pero es posible que no necesite esta flexibilidad en la práctica. La opción del medio podría estar bien en un programa simple, pero probablemente debería considerarlo como un paso en el camino hacia el tercero.

y si tiene un objeto de Pantalla (o ViewRenderer, o lo que sea) y realmente significa "una llamada de método separada en el programa principal", entonces probablemente debería reconsiderar su diseño.

0

No, los objetos no pueden suicidarse. Cualquier referencia de sí mismo es solo una referencia.

Para "borrar" el objeto dentro de uno solo borraría todas las variables de instancia.

Para "borrar" el objeto fuera de sí mismo uno establecería la variable igual a nulo.

Cuestiones relacionadas