Can an object remove itself? How?

Question

I\'m trying to write a simple ball game, and there\'s several turns (ie., ball lives). The ball \"dies\" when it passes the bottom border of the screen. What I have so far w

Answer 1

The object can remove itself given it has some sort of reference to the view rendering mechanism. Your sample doesn't give enough information so I'll exemplify one way to do it:

public class Ball {
    private ViewRenderer view;

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

Neither suicide nor murder is better or worse. It depends on your design and requirements.

In this sample though, murder might be preferable since this way the Ball object doesn't need to know in which context it's being used.

Answer 2

There is presumably some object (e.g. the Screen, or the ViewRenderer in Johan's example) that holds a reference to the Ball, and removing this reference has to be done by the Screen ("object murder"). "Object suicide" amounts to Ball passing a message to the Screen asking to be "murdered".

Since it is the Ball that knows when it has passed the boundary, it makes sense to me (without knowing the details of your design) for the removal to be initiated by the Ball. Then the Screen can find out about this change by one of several means:

• The Screen can poll the Ball.
• The Ball can hold a direct backward reference to the Screen, which creates an unfortunate circular dependency.
• The Ball can hold a reference to the screen via a BallObserver interface. This is an application of the observer pattern.

The first is simplest, and this makes it a good choice if it fits naturally into your mechanism for painting the screen. The third is more flexible in principle, but you might not need this flexibility in practice. The middle option might be OK in a simple program, but you should probably consider it as a step on the way to the third.

And if you don't have a Screen (or ViewRenderer, or whatever) object and really mean "a separate method call in the main program" then you should probably reconsider your design.

Answer 3

In a sense of deleting the object from memory: no, in Java that is handled by the garbage collector exclusively.

What you could do is to remove the object from collections containing it, but this would require the object to have access to those collections (which in most cases would not be feasible, since there might be a lot of collections).

I'd suggest the containing object (the screen in your case) to poll for the contained object's (the ball's) state and remove it after it is actually dead.

Answer 4

It is possible to create a method in which the ball removes itself, but it's a bad thing to do. In order to remove itself from the screen, the Ball must have a reference to the screen. This creates a circular chain of references (Ball has a reference to screen, screen has a reference to Ball) which is going to make your design more complicated and your testing much more complicated.

Suicide is fine - the screen tells the ball to die, and the ball dies. But this is about removal of a relationship, not dying. The thing maintaining the relationship is the screen, and so it should be the thing doing the removal.

Also remember that the two do not necessarily have to happen together. The screen might want to keep a dead ball around for some reason, and it might want to remove a ball that isn't dead. Even if that doesn't happen in your app right now, allow for the possibility.

Answer 5

No, objects cannot suicide. Any reference of itself is just a reference.

To "clear" the object within itself one would just clear all instance variables.

To "clear" the object outside itself one would set the variable equal to null.