在Java中将对象从一个位置移动到另一个位置

Question

This is something I found difficult to research as it requires some explanation.

I basically want to understand the best way of moving objects around other objects and keep track of where everything is. Allow me to explain..

Let's pretend we are making a Person class and a Park class. The park class has a bunch of toys and rides for the person to play on.. These could be a Slide class, SeeSaw class, ect.. But lets say our program needs to keep track of where the Person object is at all times. If they are on the slide, we will want to ask the person class their location. For example...

//location could be set in the person whenever we move them..
person.setLocation(slide);
//now getLocation could return the object they are on (slide, seesaw, ect)
person.getLocation(); 

But now lets say I'd like to figure out who is on the Slide object that is in the Park at any given time. It would be something like ...

slide.getOccupants(); // could return the objects that are on the slide (Persons)

But now that means that when the Person moves from object to object in the Park. I'd have to say something like...

person.setLocation(seeSaw);
slide.removeOccupant(person);
seeSaw.addOccupant(person);
//this would get annoying and scary to do everytime a person moves...

So would creating a method to handle all of these changes be the way to go? For example every time a person moves, it could call this code...

//person being who you're moving and the ride being where you're moving them to..
public void move(Person person, Ride ride){
    person.getLocation().removeOccupant(person);
    person.setLocation(ride);
    person.getLocation().addOccupant(person);
}

I can't help but feel there's a better way to do this as it feels to get messy on larger scale. Perhaps I am overthinking it but I'd love to know of any best practices or designs when it comes to this.

Thanks.

Answer 1

According to the Functional Programming folks, you hit a real problem of OO. As a purely OO driven world does not allow you to represent this problem in consistent ways. No matter how you do it, you end up with one of three possibilities:

• person X is nowhere
• person X is in two locations
• you don't know where person X is

So the real problem here is that you have multiple objects, and moving locations changes the overall system state. All fine without threads, but as soon as you have multiple threads kicking in, different threads might see inconsistent states.

The FP folks thus tell you that you first of all need to address that conceptual problem, by having a function that "moves" the system from one valid state into another valid state. Very much like your move() code, but without inconsistently updating "object states" whilst being in that method.

OK, but that is probably not what you are asking for. One answer to your problem is: think of moving a person as a service . You have entities (people, locations), and that service is responsible for "moving" things around.

And guess what: then your first implementation is a good start. So, actually, for an "educational" project, you are doing fine. Probably you should think about decent interfaces to use (to abstract the details of the "things" that get moved, or the places they move from/to). Put that into a specific service class, and work from there.

Answer 2

To maintain the history and current information about who is and was at a Location , you don't have thousand of choices : you have to save them somewhere.
Your sample code shows a way to do that.
Another way would be to use AOP by applying an Aspect that updates the state at each time a person moves somewhere.
But if you did that to spare 3 or 4 invocations, it seems overkill.

About the actual code, you can factor this processings with a method that accepts any Location to be more generic such as :

public void move(Person person, Location newLocation){  
    person.getLocation().removeOccupant(person);
    person.setLocation(newLocation);
    person.getLocation().addOccupant(person);
}

In this way, it is much more straight for the client code.

As a side note, a Location instance should probably not be responsible to set itself the set of any Location . It gives to it too much responsibilities.
You could separate the concerns by delegating the processing to a Locations class responsible of the state change.

Answer 3

One possible solution is to, instead of constructing a whole new move method which creates the feeling of excessive code, allow the setLocation method for the person to essentially use the same code as the move method you constructed (remove the person from the current park toy and move them to another) . This will allow for cleaner code, and should keep all functionality the same.