Referencing from one obj to another

So lets say I have several classes.

public static void main(String arg[]){
		MapBuilder mainMap = new MapBuilder();
		Player mainPlayer = new Player(mainMap);
		Screen mainScreen = new Screen(mainMap, mainPlayer);
}

My question is about how to enable them to work with and reference each other. Basically, I want the player object to be able to use the maps methods and the screen object to be able to use the player and the map methods. As you can see, right now I have it setup so that the references the map get sent to the player and the screen constructors and the player object gets sent to the screen as well. So, first question, is this an appropriate way to be doing this? It works, but I don’t know if its considered good programming.

But even if that is a good way to do that, I have a problem. I also want the map object to be able to reference the player and the screen. However, when the map is initialized, the player and the screen haven’t been initialized, so I can’t pass them to the constructor.

Hopefully that’s enough for you to understand what I’m getting at. So am I on the right track? Or am I going about this the completely wrong way?

Quick fix: Make MapBuilder a singleton, oh and also call it Map. It is the Map not the MapBuilder. That seems like it would be a quick fix to your problem.

A good rule of thumb is to avoid so much inter-dependancy as it leads to a difficult to maintain codebase. Try to make things as modular as possible (without going crazy, find a good balance that leans more towards the modular side).

Long term fix: Keep practicing and don’t be afraid to hit the books. They will teach you a lot. I recommend “Effective Java” if you have not read it yet. It will teach you tons, and help you solve problems like this.

hmm…hadn’t heard of singletons before. Just read up a bit on it. Sounds likes its basically an object with a static constructor, which prevents more than one of it being created. Since its static, I can just reference the object’s methods with the class name…That would work.

Thanks for the book suggestion. I’m currently reading through thinking in java, but I’m gonna need something to read after that.

Just note that while it might be a quick fix, if it involves a singleton it might also be a long con.

Pretty simple, you can create 2 methods in the map class along with 2 variables, 1 for the player and 1 for the screen, like so:

private Player player
private Screen screen

public void setPlayer(Player player){
this.player = player
}

public void setScreen(Screen screen){
this.screen = screen;
}

Then:

Map map = new Map();
Player player = new Player();
Screen screen = new Screen();
map.setPlayer(player);
map.setScreen(screen);

This gives you the ability to use the player and screen instances inside your map class. I’m worried that things could become a little fiddly with your code due to passing things everywhere. Would it not be simpler to have something like a GameController class that takes in the player & map in the constructor and then handles all the code in that class. This would solve issues with jumping from class to class and getting you confused

Yeah, there we go! That’s exactly what I’m looking for. Specifically what you said at the end about using a game controller. (Although using the setPlayer/setScreen methods are a great quick fix)
Like I said in the original post, I was afraid I was just going about this the wrong way. So what you’re suggesting is a GameController class that acts as a sort of mediator between all the other class. That way if the player class “needs” to use a method from the map class, it’ll just call the GameController and then the GameController will handle the rest. So for that I would just need pretty much all the class to have a reference to the GameController (which shouldn’t be a problem) and the GameController to have the references for all the other classes?

I should of named the controller better really. Lets say we call it mapHandler. We want the map handler to have a constructor that takes in the player and the map and have 2 private variables that hold the player and map references. This handler can then use methods such as:

public void playerMapCollision(){
if(player.bounds.overlaps(mapCollisionGoesHere)){
do this stuff here
}
}

This means that you aren’t going back and forth between classes and the handler can just call the methods that are needed due to holding a player and map reference.

The player/map/screen or any other class does not need a handler variable as they will only hold information regarding things like position, colour, name, age, health etc and then the handler can use the references of the other classes to manipulate the data

Alright, I think I follow you so far. Let me ask you a more specific question. So the user inputs a command to move to the left. What would you think would be the most efficient way to handle this? Right now, the way I kinda have it setup is the command first gets passed to the player. The player then updates it’s variables for its current position. Then it passes its new position as well as its previous position to a method in the map. The map itself btw is just an array of chars. The map then removes the player from its previous position and puts it into its new position in the array. Finally the screen object updates and prints out the new map. It works for now. But of course in the future it’ll to need to check to see if the next position is open. If there is a wall in the way, of course the movement cannot be done. My question would be where in the flow should this check be done? Or should the flow be completely redone? What I have works for now, but I have the feeling it’ll get really messy when I start to add stuff. I also realize that there’s not really a “correct” answer to this, but I guess I’m really just looking for suggestions/critique.

Edit: I would think that the best solution would be incorporating the maphandler like you suggested. So instead of the player passing it’s new position to the map, it would pass its proposed new position to the maphandler, which would then check the map to see if that position is clear, if it is, it would update the map, but if not, it wouldn’t the update the map…
And honestly, I think that at this point, I’d might be better off just combining the map and the map handler. After all, the “map” is really just nothing more than an array, and I don’t know if that warrants its own separate class…but then again…its just an array for now… I imagine it would likely become more complex as I add things (such as multiple objects stacked at the same position) so maybe having a separate class is a good idea…

anyways, now I’m just thinking out loud.

The way I handle my map collisions/movement of the player is to have a class called playerHandler. Hopefully I can sum this up easily.

public class playerHandler(){
private Player player;
private Map map;

public playerHandler(Player player, Map map){
this.player = player;
this.map = map;
   }
}

playerHandler has a method called playerMovement() which gets which key was moved so the player can move. The handler has access to the player instance remember as we passed it through the constructor of the handler as well as the map. We can then check which key is pressed, if the player collides with anything such as a map object etc. We can do this all inside the handler class. We then would want to update the player location on the map and we can use the map variable inside the handler to call a method such as setPlayerLocation(player.getX(), player.getY()); see?

We are making everything happen inside the handler class using the variables and then simply calling any methods from the classes we need inside the handler.

I hope this makes sense D:

So if we delve deeper into the way that variables work what happens is when you do something like say obj a = new obj(constructer parameters); a is not the object but rather a reference to the memory location . When we combine this with the way that java interprets its code , in a sequential manor , you can understand that if you reference obj b in the constructor of obj a but define obj a before obj b then the pointer to that memory hasnt been created.
The easiest way to do this is to create the new objects and move the data from the constructor into an init() method , so after obj b is created you call a.init(); and it will work.

I’ve been stuck on this for ages back when I first started programming. For a quick and easy method if your game isn’t very big and complex, you could make the map, player and screen all static in your main gameplay class, then you can make them interact with each other by referencing to them as Main.player etc.

If the map wants to access the player object, for example, you would do something like Main.player.someMethod() in the map object.

Another way you could do it is by parsing the main game class to the player, screen and map objects when you initialise it (using a constructor), then accessing the main game class’s objects.

E.g. player = new Player(this) in your main class.

Then in your player object, you can go this_maingame.map etc

Or just don’t require that the Map knows about the player. I don’t see why one would.

When I program sometimes I have a camera object within my player object and then handle the render of tiles within the world map so the player would be required.

Perhaps the “player” can or should be a parameter to the various map methods rather than an instance variable. That would be more of a “Functional Programming” way of coding.

Seems like you are trying to do too many different things with one class. The Map sounds like it should be data-oriented. Another class could be responsible for the rendering, using the map as one of the input parameters.

If you are looking for Java books to read, I’d also like to recommend “Clean Code” by R.C. Martin. I happen to be rereading “Effective Java” at the moment, or rather, consulting it once again. It is a terrific book, but not an easy read at all. It took me 3 or 4 attempt and a couple years of experience to finally get to where I could make sense of the terminology and ideas. I still wouldn’t say the book was entirely comprehensible to me.