I am sure this has been said, but as someone said earlier your player class should not do any collision control. In good OOP your player should not need to know anything more then it has to, if it has an inventory it should not "know" what is in it, the inventory class should know what is in it and the player should be able to choose based on what the inventory class lets it (just an example).
For yours the "world" class should hold a instance of your player class. As well you might want to make it so that for a simple game you have a 4 x 4 grid that looks like this
ttrt
mtrt
rrrt
mmmt
In that if your system sees a t and shows a tree, a r and shows a road, and a m shows a mountain. If a P is there it would show the player, this would be a very basic demonstration. However as said above if your world holds an instance of your player and your player holds the location of itself, then it can simply send that information (through something like player.getCoords(); that sends an array (2 values) that are its location, check if it can move to the next location and if it can then do so, if not don't let it.
I would not do what the person above me suggests, keeping your player class and tile class separate is actually better OOP, as well it allows you to add multiple players into your "game" if you wanted to instead.
But your player "program" should not do collision detection. That is because in OOP each class should only know what it needs to know.
Sorry for the large amounts of redundancy